Як реанімувати старий безнадійний проект. Частина 2 : Тимбилдинг

via Shutterstock .

Перед прочитанням цієї статті рекомендуємо ознайомитися з попереднім матеріалом : «Як реанімувати старий безнадійний проект. Частина 1 : Рефакторинг vs переписування з нуля ». Муки вибору : формат команди та проекту Крім першої проблеми - « рефакторинг vs переписування з нуля » , вас чекає не менш захоплююче завдання - побудова команди та проектів . Ви можете:
1 . Створити дві конкуруючі команди . Одна з них супроводжує старий проект , друга - пише новий .
2.Создать два проекти ( новий і старий ) в рамках однієї команди . У першому випадку стара команда залишається супроводжувати вмираючий проект , поки нова команда з нуля переписує систему. Варто застерегти від спокуси випускати переписану систему тільки після повного повторення функціональності старої системи . Найчастіше таке рішення призводить до дуже тривалих протистоянню між старим і новим проектом , час розробки нового проекту затягується через невиправдано високих очікувань по функціональності. Програмісти відчувають тиск з боку менеджменту , а від старої команди все частіше чути смішки « вуж два рочки як чекаємо релізу ». В таких умовах програмісти « нового » проекту змушені поспішати і робити помилки , вони пишуть « брудний код» , частина з них розчаровується і покидає проект , а через час ви отримуєте хаос нітрохи не краще, ніж в старому проекті. Щоб уникнути цієї долі , потрібно встановити розумні рамки функціональності нової системи . Це той самий випадок , де без MVP і розумного системного аналітика вам просто не обійтися . А щоб уникнути непотрібної конкуренції між командами - ізолюйте їх один від одного , розмістивши офіси розробників , наприклад , в різних кінцях міста . Сполучною між старим і новим проектом повинен виступати аналітик , але ніяк не розробники . Дуже часто зустрічається ситуація , коли стара команда нічого не знає про написання нової замінної системи . Це один з найгірших варіантів , з яким ви можете зіткнутися , бо в результаті породжуються відразу кілька ризиків : якщо заздалегідь не потурбуватися про те , як ви будете старій команді пояснювати причину її раптового розпуску , то про вашу фірму поповзуть неприємні чутки в професійному середовищі. Якщо про ситуацію стане відомо новим розробникам , що швидше за все і станеться , то вони цілком справедливо можуть порахувати , що ви з легкістю можете вчинити з ними так само. Чому роботодавці не доводять до відома розробників старої команди про написання нової системи? Вони турбуються , що команда , дізнавшись про швидке закриття свого проекту , відмовиться його супроводжувати . Знайти вихід з цієї ситуації , морально підготувати команду і коректно повідомляти їй ці непрості новини - ще один головний біль , про яку потрібно подумати заздалегідь . Випускати нову систему як замінник старої або створювати внутрішнього бренд - конкурента - питання до маркетолагами , але над цим теж слід подумати завчасно . Зрозуміло , ні про яке рефакторінгу при використанні даного підходу мови бути не може. Така стратегія підходить тільки в разі переписування системи « з нуля ». Другий спосіб організації команд і проектів - це створення старого і нового проекту в рамках спільної команди. Для реалізації цього плану в команду вводяться новий системний архітектор і аналітик . Ці дві ролі починають роботу над новою системою . Аналітик збирає вимоги до нового проекту , на базі цих даних архітектор приймає рішення про необхідної архітектурі системи . На базі прийнятих рішень створюються таски , які поміщаються в загальний пул завдань . Суть цієї стратегії полягає в створенні « конкуренції з самим собою». Старі розробники отримують реальні завдання з нового проекту , які вони виконують відповідно до нових вимог системного архітектора по новим для них стандартам. В результаті розробник може порівняти старий підхід до розробки ПЗ з новим , «помацати » запропоновані технології і зрозуміти їх. А всім нам відомо , що « до хорошого звикаєш швидко » - розробники мотивуються якнайшвидше повністю перейти на новий проект і забути про стару систему як про страшний сон. Крім побудови бізнес архітектури та системної архітектури , аналітик і архітектор відповідають за теоретичне і практичне навчання старої команди . А так же за побудову нових стандартів розробки ПЗ. Після закінчення деякого терміну всі старі співробітники повинні успішно пройти внутрішню атестацію , щоб продовжити роботу на новому проекті. Підтримка старого проекту по мірі необхідності припиняється. Варто згадати , що команда буде перешкоджати прийдешнім змінам усіма можливими засобами . Варіант « всіх звільнити » нам не підходить , т.к. хтось повинен супроводити старий "не- зрозумій - як - працюючий » продукт . І щоб мінімізувати згубний вплив на прийняття рішень в рамках нової системи - дуже бажано виділити для «Проекту 2 » окреме дорадче приміщення (і це не повинен бути загальний мітинг - рум ) . Успіх даної стратегії багато в чому залежить від доступності необхідних ресурсів . Після первинної оцінки обсягів майбутньої системи , архітектор і аналітик можуть запросити в команду одного або кількох нових фахівців . Як правило , для цього є вагомі підстави , будьте готові до цього. З недоліків цього методу можна перерахувати :
1.Сложності при пошуку достатньо грамотних і комунікабельних архітектора та аналітика , які погодяться навчати команду .
2.По закінчення часу частина розробників доведеться звільнити, тому що , швидше за все , для супроводу нової системи знадобиться набагато меншу кількість програмістів , ніж для старої . Однак , замість того щоб відпускати тлумачних людей - можна перенаправити вивільнені людські ресурси на нові напрямки та проекти. Таким чином , мінус може перетворитися в плюс . Дана стратегія застосовна як для повного переписування системи , так і для глибокого рефакторінга поточного проекту . Який би підхід до побудови команд і проектів ви б не вибрали - попередньо дуже бажано провести аудит проекту і девелопмент - процесів . Адже перш ніж « лікувати » , потрібно з'ясувати « діагноз ». Найпростіше попросити про таку послугу знайомого архітектора та аналітика з будь-якого успішногопроекту , яким ви можете довіряти . І на завершення , завжди пам'ятайте : вашу команду формують особистості , у яких є свої переживання і думки . У них різні характери , звички і комунікативні здібності . Успіх вашого підприємства в більшій мірі залежить навіть не від технічного рівня фахівців , а від особистих якостей цих людей. Кожен з ваших розробників - маленький « станочек » у вашому IT бізнесі - він створює продукт , який ви продаєте . Ніколи не забувайте , що вони - живі люди , ставитеся до них по - людськи , і тоді дуже велика ймовірність , що вони дадуть відповідь взаємністю . Післямова Як переконливого аргументу привожу правдиву історію програміста - нині запеклого системного архітектора , який намагався отрефакторіть проект , не маючи політичної підтримки згори . Розповідь від першої особи , от як це було: «Коли я прийшов у цей проект , я поняття не мав , що такможна працювати. У попередній команді був постійний кодревью , «били по руках » за неправильне ім'я змінної , криво написану функцію , неправильно вибраний алгоритм , не той застосований патерн проектування і.т.д. У мене був дуже гарний код . У мене був правильний стиль . У мене була підтримка з боку ( мій же код постійно дивилися ) , і ймовірність помилок падала експоненціально . Саме такий « світлий » , « викарбуваний » я прийшов. Перше , з чим я зіткнувся , - це хаос. Натуральний кошмар . Хоча в тому безнадійному проекті теж була своя « система ». Був таск - менеджер , були таски , терміни , код . Головне , чого не було - це стандарти . І перше , що я зробив , - за тиждень написав стандарти кодування : як змінні іменувати , які відступи , куди ставити скобочки , як писати запити , які класи використовувати і.т.д . Спочатку стандарти обсміяли . Потім все- таки їх винесли на ранковий мітинг . На мітингу їх бурхливо обговорили , перевели в холівар :
- А ось я звик користуватися пробілами !
- А я звик користуватися табами ! ..
І так далі. Що потім? А нічого . Кожен залишився при своєму , і мені сказали :
- Ось бачиш , що не будуть все писати однаково. Як має поводитися керівник в цьому випадку? Жорстко взяти і сказати : « вистачить бардака ! Робимо так і так ». Влаштування балагана і/або « хай все вирішує загальні віче з ранку раніше » - це банальний відхід від відповідальності . Ні системного підходу - бардак ! Бардак здатний вирішувати задачі , але не здатний робити це ефективно . Бардак не здатний швидко виправляти помилки. Бардак не здатний не допускати помилки. Бардак здатний плодити помилки. Коли замість набору if ( ) ... if ( ) ... if ( ) я запропонував використовувати Абстрактну фабрику , все , крім одного хлопця , запитали: «Що? Що це? »- Це було показово . Є шаблони проектування. Вони не зі стелі придумані . І це не рівень « подобається - не подобається ». А це рівень « підтримується - не дозволені ». Я спробував впровадити неймспейси , але це було зроблено некоректно . Багато речей я тоді не міг по -іншому впроваджувати - від начальства я отримував завжди відмова типу : « а нафіг воно треба ? » , Тому все впроваджувалося так , щоб не поламати те, що вже є. І щоб цих змін по можливості ніхто не помітив. Я намагався впровадити масове код- рев'ю - не вийшло . І справа не стільки в інструментарії , скільки в тому, що: « та хто ти такий , що вказуєш мені , що робити з моїм кодом ? Ти скільки тут працюєш ? Два місяці ? А я - два роки. Фігово написано? Не твого розуму справи. Працює ? От і не компостують мозок ». Я переписував тихо . Один хлопець там вмів сперечатися і доводити. Якщо не вийшло довести - він не виправляв нічого . Працювало , як працювало . Я ж мовчки і без шуму щось міняв сам , і тихо радів своїй роботі . Ніхто цього не оцінив . Зрештою я пішов. Мене чекали нова компанія , новий світ , бурхливе зростання , усвідомлення власної дурості . Ти питаєш , чому я пішов : я почав тупеть . Дуже сильно. За тиждень до відходу я відкрив фрагмент коду , подивився і отетерів : він був дуже красиво написаний. І мені стало цікаво , хто ж у нас так красиво пише . І коли я зрозумів , що це був мій код , написаний в перший тиждень в цій конторі , - мене вразило , як сильно я деградував . А на новому місці в перший місяць я дуже тупив . Я радий , що пішов у нову компанію , де мої якості оцінили по достоїнству. Дуже приємно займатися улюбленою справою , реалізувати себе , бути потрібним і шанованим фахівцем , та ще й отримувати гідну компенсацію за свою працю " . Сердечно дякую Славу Конашкова за професійні консультації та допомогу в написанні цієї статті .

Опубліковано: 18/11/14 @ 08:39
Розділ Різне

SEO Блог

Як реанімувати старий безнадійний проект. Частина 2 : Тимбилдинг

Рекомендуємо: