“Стати крутий командою програмістів можна за півроку-рік”

Forbes.ru продовжує публікувати інтерв’ю з відомими діячами російського сегменту інтернету. Сьогодні про те, як виглядає створення нових інтернет-сервісів очима не підприємця, а розробника, розповідає керуючий партнер компанії ScrumTrek Асхат Уразбаєв.


Максим Спиридонов: В останніх випусках “Рунетологіі” ми часто з ретельністю закопувалися в бізнес, говорили про гроші та управлінні процесами. Сьогоднішня тема, з одного боку, лежить в стороні від звичних питань, освітлюваних програмою. З іншого – прямо на них зав’язана. Ми поговоримо про інноваційні, гнучких способах програмування та веб-розробки. Наш гість – тренер по Agile і Scrum Асхат Уразбаєв. Асхат, в тренінгах, які ти проводиш, чого ти прагнеш добитися від тренованих? Що ти впроваджувати?


Асхат Уразбаєв: Це залежить від того, чого ви хочете домогтися від Agile і Scrum, тому що вони вирішують різні проблеми. Для мене найголовніше – зробити команду розробників більш ефективною, щоб вони могли вирішувати завдання, удосконалюватися.


– Слова Agile і Scrum останні рік-півтора звучать часто, але, як мені здається, у багатьох менеджерів немає розуміння того, що ці слова означають.


– Так, є вузька тусовка, яка ці слова застосовує.


– Чи є статистика по тому, як змінюється продуктивність при впровадженні в команду Agile, Scrum та інших методів гнучкої розробки, яким ти навчаєш?


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


– Те, що робилося місяці, робиться за десять днів?


– Так, але це суб’єктивний параметр, тому що ніхто не міряє веб-розробку термінами. Коли нас запитують: “Як збільшується продуктивність?”, Ми запитуємо у відповідь: “А в чому ви її зараз міряєте?” Кажуть, що ні в чому. Продуктивність ні в чому не міряється, і виходить, що її немає з чим порівнювати. Залежить від ступеня бардаку, який панував раніше. Якщо все було зовсім погано, то збільшення буде великим.


– За твоїми спостереженнями, наскільки висока ступінь безладу в тих проектах, куди ти приходиш? Що і як змінюється після твого приходу?


– У нас молода індустрія. Компанії не встигають напрацювати загальні практики. Умовно кажучи, фірмі 3 роки. Її не можна порівнювати з компаніями, які працюють 40 років. Чим вона молодша, тим вище ступінь бардаку. На першому етапі це позитивний бардак, який приносить користь. Компанія росте, доходить до 30 розробників, і стає важлива ефективність взаємодії всередині колективу, інакше виникають проблеми. Чим старше компанія, тим більше у неї проектів, тим вище ступінь безладу, що заважає жити. Тоді компанія і починає замислюватися, що з цим можна зробити. Agile і Scrum – один із способів щось змінити, і, як мені здається, спосіб найефективніший. У Agile самоорганізована і самокерована команда, немає сильної залежності від ключових розробників, тобто немає людини, яка роздає завдання. Всі люди знають проект.


– Якщо залишиться одна людина, то він буде володіти всією інформацією?


– Всією немає, тому що проект великий, але важливу інформацію він буде знати. В хорошому Agile-проекті все приблизно однаково володіють інформацією. Це називається “спільним володінням кодом”.


– Це не ускладнює процес?


– Ні, це його полегшує, тому що знімає ризики, пов’язані з доглядом ключових розробників. І здешевлює процес. Наприклад, у тебе є план ітерацій на тиждень. У тебе є одна людина, яка знає один конкретний шматок коду, наприклад розбирається в якійсь функціональності. Крім нього, ніхто не може займатися цією частиною. Уяви собі, що конкретно він не може зараз працювати в цій ітерації, а ти припускаєш, що він буде займатися розробкою цієї функціональності. Що ти предпрімешь в такій ситуації? Або, наприклад, три розробника не взяли три фічі. Кожен може взяти в розробку одну фічу і займатися нею протягом тижня. Потім несподівано закінчується ітерація, і виходить, що ні одна фіча не зроблена. У Agile і Scrum ми намагаємося взяти одну фічу усією командою з трьох осіб, доробити її, протестувати, а потім взятися за наступну. Спільне володіння кодом дозволяє нам так працювати. У підсумку стабільність результату ітерації вище. Імовірність того, що ти зробиш основні фічі до кінця, вище.


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


– Так, тільки це відбувається в рамках ітерації.


– Поясни мені, що таке ітерація і навіщо вона потрібна?


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


– Наприклад, якщо говорити про Freshforex.ru з великою командою, проблема полягає в термінах і стабільності роботи функцій. Там п’ять розробників, але їх не вистачає. Поставлені терміни не виконуються, я не знаю, з якої причини.


– Ти не знаєш, чому терміни не виконуються? Вони обіцяють якісь терміни і їх не витримують?


– Мабуть, терміни невірно оцінюються керівництвом відділу.


– Чому невірно? Невже складно правильно їх оцінювати? Якби ти їх запитав про це, вони б сказали: “Час від часу відбуваються зміни і щось необхідно переробляти”. Як ми будемо вирішувати цю проблему? Ситуація, напевно, така: сидять п’ять розробників, у кожного своя грядка, яку він прополює, приходять зміни на грядку якогось одного розробника, і йому потрібно впроваджувати ці зміни. У цей час сидить Оля, у якої є вільний час. По-перше, вона стажер, і їй не дали великого завдання. По-друге, особливих змін у неї немає. Петя ж, якому прийшли зміни, перевантажений: він уже робить два завдання в паралелі. Він практично виконав одну задачу, і в цей час прибігає Вася і дає йому ще одну задачу. Тепер Петя робить три завдання. Йому не дають нічого закінчити. Чим далі, тим більше у нього завдань, і закінчити їх він не може. Давай спробуємо зафіксувати обсяг робіт на якийсь період. Наприклад, на тиждень ми плануємо якийсь обсяг робіт – і ми виконуємо його за цей тиждень.


– Не беручи інших завдань?


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


– Ітерація – це тиждень?


– Залежить від конкретної ситуації. Як правило, ітерація – це термін від тижня до місяця.


– Хто визначає розмір ітерації в кожному конкретному випадку?


– Команда, замовник, менеджер, керівництво. Або спільно. Потрібно підібрати довжину ітерації, яка буде зручна.


– Розкажи сенс поняття Scrum простими словами.


– У тебе крос-функціональна команда …


– У мене команда, в якій всі знають код продукту. Під чиїм керівництвом вони виконують роботу?


– Під керівництвом власника продукту. Давай візьмемо конкретний приклад. Наприклад, у тебе стартап, і у тебе є project-менеджер, який відповідає за те, щоб цей стартап був успішним з точки зору бізнесу. У нього певний набір завдань, які, як правило, сформульовані на рівні бізнесу, тобто це бізнес-вимоги, не технічні. Конкретні форми і звіти, на які можна подивитися і зробити висновки. Список такої функціональності називається беклогом, списком фічей, списком вимог. Product-owner займається його координацією, він відповідає за пріоритети. У ітерацію ми намагаємося брати пріоритетні фічі і займатися розробкою цих фічей. У Scrum вони називаються спринті.


– Agile і Scrum – різні речі?


– Agile – це більш широке поняття, ніж Scrum. У Agile входять Scrum, екстремальне програмування і Lean. Scrum володіє меншим набором практик. Повернемося до прикладу. У тебе є беклог, product-owner, команда і спеціальний людина – Scrum-майстер, який стежить за тим, щоб люди дотримувалися правила, щодня збиралися на летючки, які називаються daily Scrum meeting (люди зустрічаються на 15 хвилин, щоб обговорити план на день).


– Є список завдань, менеджер, модератор. Що відбувається спочатку?


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


– Чи не входить це в протиріччя з тим, що докладний план – формалізація, якої часто хочеться уникнути?


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


– Це пов’язано зі специфікою російського програмування, в якому взагалі не прийнято документувати?


– Так. У тебе є невеликий план, за яким ти щодня працюєш і який допомагає тобі керувати проектом. Команда протягом ітерації за цим планом працює, і він потрібен їй, а не менеджеру. На протязі ітерації команда щодня зустрічається на daily Scrum meeting. В кінці ітерації результат показується замовнику і обговорюється, які фічі зроблені, які не зроблені і що потрібно переробити. В твоєму прикладі це виглядало би наступним чином. Був би беклог, прибіг би Вася чи Петя і сказав, що треба ще щось зробити, був би product-owner, який додав би ще один пункт і вставив це в план наступної ітерації. На загальні терміни це вплинуло б, але була б прозорість, було б зрозуміло, що зроблено, а що ні. Фічі б робилися, тобто фічі були би закінчаться до кінця, а потім розробники бралися б за наступні. Це не відкладало б терміни поточних фіч.


– За твоїми спостереженнями, наскільки проблема перевантаження виконавців поширена в російських проектах?


– У 90% випадків це так.


– Реальна проблема у 90% компаній полягає в тому, що виконання завдань не може завершитися, тому що з’являються нові?


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


– Не ставить непереборних проблем менталітет?


– Це залежить від культури всередині організації. Питання в тому, чи відчуває команда цінність у формалізації. Якщо люди відчувають цінність, то вони із задоволенням беруть нові методики. Наприклад, Петя перевантажений, і йому говорять, що робота буде організована по-іншому: у тебе буде проект на певний час, ти зробиш цю роботу, вона буде здана замовникові, і тільки потім ти приступиш до нової роботи. Тобто він не займається одночасно десятьма проектами, він займається одним проектом, але йому доведеться приходити на daily Scrum meeting і демонструвати результати. Людям зазвичай це подобається. З мого досвіду, команди веб-розробки добре приймають Scrum, вони відчувають, що це захищає їх від деякого свавілля з боку менеджменту.


– Давай поговоримо про твоє досвіді: скільки компаній ти перевів на рейки подібної роботи? Як це відбувається?


– Кілька десятків компаній з різним ступенем залучення. Найчастіше це коучинг: ми беремо компанію, складаємо беклог, тобто список вимог, потім плануємо реліз – вирішуємо, коли закінчимо заплановані дії, далі плануємо ітерацію, потім її закриваємо. Закриття – демонстрація результатів і ретроспектива за підсумками, тобто ми вирішуємо, як поліпшити процес. Протягом якоїсь кількості ітерацій ми працюємо спільно. Ми з Микитою приходимо на daily Scrum meeting, наше завдання допомогти команді придбати самосвідомість. Хлопці спочатку являють собою групу людей, поступово вони починають замислюватися про цілі проекту, стають справжньою командою, людьми, які хочуть підвищити власну продуктивність.


– Скільки по часу це займає? Наскільки складно переучувати програміста?


– Кілька місяців. Потрібно разом пройти як мінімум чотири ітерації. Стати крутий командою можна за півроку-рік, в залежності від ситуації. Є компанії, з якими ми працюємо по три роки.


– Програмування – це досить інтровертна професія, а тут відбувається повернення до спільної роботи, що позитивно впливає на команду.


– Так. Якби хлопці були екстравертами, любили спілкуватися, тусити і генерувати разом ідеї, то деякі практики Scrum, може, були б і не потрібні (наприклад, daily Scrum meeting). Це доповнення для того, щоб люди подолали свою інтровертність, націленість на написання коду і більше думали про те, як ефективно один з одним взаємодіяти. Проекти провалюються не тому, що люди погано пишуть код, а тому, що вони не коммуніціруют один з одним.


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


– Scrum-майстер відповідає за Scrum. У різних організаціях взаємодія виглядає по-різному. Дати загальні рекомендації можна, і я постараюся це зробити. Я просто хочу попередити: якщо у вас щось відбувається по-іншому, це не означає, що у вас неправильно. Класичний менеджер відповідає за беклог, класичний Scrum-майстер – за те, щоб Scrum був успішним. Він відповідає за те, щоб були артефакти, планування ітерацій, щоб були демонстрації, ретроспективи, щоб рішення, прийняті командою, були втілені в життя. Найчастіше команда домовляється, розходиться, і нічого не змінюється – такого бути не повинно. Команда повинна дотримуватися правил, за це і відповідає Scrum-майстер. У реальності буває по-різному. Часом product-owner відповідає за беклог і допомагає Scrum-майстру, тобто бере на себе частину його обов’язків. Або навпаки: Scrum-майстер бере на себе частину роботи власника продукту.


– А об’єднати ці ролі неможливо?


– Можливо, але є певні ризики. Припустимо, product-owner і Scrum-майстер – одна особа. Зазвичай Scrum-майстер задає такі питання: “Що ти робив вчора, що ти будеш робити сьогодні, які в тебе проблеми? “Навіщо це потрібно? Для того щоб всі розуміли, що відбувається. Якщо один з членів команди говорить, що закінчив задачу № 34 і переходить до задачі № 35, це не дуже гарна відповідь, оскільки він не розповів про те, що він конкретно зробив, що змінилося в коді, що сталося з продуктом. Якщо приходить менеджер проекту або product-owner і проводить Scrum, то, як правило, він приходить за статусом, точніше, люди чекають, що він приходить за статусом. Вони автоматично будуть говорити, що вони зробили, що будуть робити. Вони скажуть, що проблем немає. Це не daily Scrum. Виходить, що product-owner – менеджер, а Scrum-майстер – рівноправний член команди. Як тільки це починає робити одна людина, починаються проблеми. Якщо ідеї пропонує product-owner, це є тиском на команду. Product-owner – менеджер, пропонує рішення, які плюс-мінус обов’язкові для виконання. Досить важко комусь одному суміщати функції цих двох людей. Виникає проблема лідерства. Product-owner – лідер, людина, яка веде людей за собою, людина, як правило, з великим его, людина, який вирвався в лідери завдяки тому, що не боявся брати на себе відповідальність, вів людей за собою. Scrum-майстер – людина з маленьким его. Його завдання не вилізти вперед, а зробити команду більш ефективною.


– Agile застосовується тільки в очній роботі або в дистанційній роботі його теж можливо використовувати?


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


– Чи можна навести конкретні приклади, як Agile і Scrum заощаджують гроші або час?


– Ми розглядали типовий бардак, тепер розглянемо waterfall. Коли ти розмовляєш із замовником, він генерує набір фантазій – того, що він хоче отримати, але це не те, що йому потрібно, а те, чого він хоче в конкретний момент. Ми можемо звести це до списку і отримаємо збір вимог. Припустимо, через чотири місяці ми зробили сайт і йдемо показувати його замовнику, у нього – шок, тому що у випадку класичного waterfall він перший раз бачить продукт. Те, що він бачив раніше, – це прототипи. Його думка абсолютно помінялося за цей час, і сайт виглядає не так, яким він собі його уявляв.


– І звучать слова: “Це зовсім не те, що я замовляв”.


– Так. Ви піднімаєте документи, показуєте, що вам говорили, а замовник каже, що він не те мав на увазі. У Agile і Scrum ми б зібрали вимоги, у нас був би беклог, ми б почали працювати, показали б результат в кінці першої ітерації, і тут би замовник зрозумів, що це не те, чого він чекає від сайту. Ми показуємо сайт замовникові, він говорить, що це не те, що йому потрібно, концепція змінюється. Ми провалилися, але провалилися, втративши тиждень, а не три місяці. З досвіду відбувається так: з беклога (близько 100 фіч) приблизно 60 ми робимо, 40 викидаємо і 40 додаємо. У результаті ми не тільки додаємо функціонал, але і викидаємо непотрібні частини.


– Іншими словами, точно порахувати гроші неможливо. Можливо, це 100% бюджету: ви зробили те, а могли зробити на 100% не те.


– Так. Давай розглянемо два сценарії. Перший: у waterfall ми б витратили місяць на збір вимог, чотири місяці на розробку, отримали результат, показали його замовнику і витратили два місяці на те, щоб щось додати, причому більшість непотрібного функціонала залишилося б. Другий варіант: Scrum. Час на збір вимог можна сильно скоротити, тому що в Scrum вимоги збираються по ходу проекту. Спочатку – верхнеуровневие вимоги, деталі – пізніше. За один-два тижні можна зібрати вимоги, чотири місяці ми б розробляли сайт, але результат був би готовий. Ми б його віддали замовникові, і він би прийняв його. При цьому результат не містив би зайвих фіч, але наявні були б дуже цінні для замовника. Я зараз не говорю про ризики, пов’язані зі зміною концепції.


– Наскільки зараз, як тобі здається, поширені методи Agile? Скільки компаній стали цим займатися з твоєї подачі в Москві, в Росії? Скажи, який відсоток ефективно використовує цю методику?


– Відсоток я не можу назвати, але в вебі він великий – трохи менше 50%, якщо брати типові проекти. Мені подобається, що в Agile приходять лідери, компанії, які на слуху.


– Можеш назвати якісь конкретні вдалі проекти з тих, що на слуху, які робилися і робляться з використанням Agile?


– Наприклад, “Мегаплан”, “Моє коло”. Auto.ru зараз використовує Scrum.


– Які послуги ScrumTrek надає російським компаніям частіше: реанімація бізнес-процесів або профілактика?


– Реанімація.


– Застосовуєш ти гнучкі методології в звичайному житті? І як, наприклад?


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


– Питання від слухача: “Який максимальний термін впровадження Scrum в роботу невеликої компанії?” Назви і мінімальний.


– Максимальний термін не обмежений. Є такі компанії, як Microsoft або “Лабораторія Касперського”, у яких багато команд. Процес починається з однієї команди, а потім масштабується. Мінімальний термін – три місяці, напевно.


– В яких компаніях ваше впровадження Scrum і Agile можна визнати повністю провальним і чому?


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*