Як познайомити Agile з командою, яка використовує жорсткі негічні методи?

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

Як ви ставитесь до того, щоб впроваджувати Kanban чи Scrum поступово, не порушуючи всієї їхньої системи і все ще впевнюючи їх, що це все ще може бути таким же підзвітним / аудиторським ?

Я знаю, що це, можливо, пов’язано з " Як би ви запровадили гнучку методологію на зразок Scrum ", але тут я цікавлюсь способами обійти / подолати той факт, що компанія нав'язує певний спосіб управління SDLC під помилковим приводом, що це єдиний спосіб провести аудиторський слід.

Я думаю, що це міф про те, що команди Agile проекту не документують своїх заявок, і це перший пункт опору, який ви отримуєте в компаніях, які мають сертифікацію з найкращою документацією відповідно до своїх стандартів.

Я працюю в сертифікованій компанії ISO-9001, але ми ТАКОЖ робимо Scrums для великої кількості наших проектів. У нашому випадку зміна відбулася від керівників проекту (тобто досить старших людей), і тому вона приймається - на відміну від менеджера проекту або розробника, який намагається втримати цю зміну.

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

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

Принцип Agile - це "достатньо" документації. Чи можете ви спробувати відштовхнутися від Замовника, щоб висловити команді, скільки всього достатньо? Керівник проекту може поговорити із замовником і зрозуміти, які їхні очікування та організаційні потреби, а потім і документувати рішення, і відповідати цим очікуванням. Якщо це досить добре для них (тобто платні клієнти), то це може бути тим, за чим ви слідуєте.

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

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

Agile - це набір навичок, які команда може засвоїти, що значною мірою є ортогональним для наших традиційних технічних навичок. Але якщо ви додасте це до своїх існуючих навичок, звичайно, ви можете стати більш ефективною командою. Щоденні збори (тобто зустрічі Scrum) не будуть можливі протягом ночі - але у вас зараз будуть регулярні збори команди (скажімо, щотижня)? Я б сказав, для початку перетворіть їх на дотримання порядку денного питання Scrum (не надто підступно;) і донесіть до ширшої команди, чому такий підхід може спрацювати і не означає слабкої документації / поганих стандартів чи будь-яких інших міфів.

Спершу я б відокремив Scrum від Kanban.

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

Scrum принципово відрізняється в тому сенсі, що це щось, що витіснить існуючий процес.

Команді, яка звикла до 12-місячного (або довшого) циклу SDLC водоспаду, дуже важко буде переходити до Scrum. Поступове скорочення циклу до 6- або 3-місячних поїздів, що випускаються з меншим розмахом, може бути корисним проміжним кроком.

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

• Запитайте себе, чому ви хочете використовувати Scrum . Вам потрібно вирішити справжню проблему?
• Слідкуйте за тим, щоб ви були прихильні до цього, бо ніхто цього не зробить за вас. Ви будете власником речі. Принаймні, поки це не принесе позитивних ефектів в організації
• Тренуйте себе . Книг та Інтернету недостатньо. Спершу перейдіть на курс, або ви різко збільшите свій шанс неправильно реалізувати Scrum. Це, ймовірно, призведе вашу команду до гірших результатів, ніж раніше
• Продайте спочатку команді . Ви повинні мати їх повну підтримку, очевидно
• Не пропонуйте змін, запропонуйте тест . І вважайте це так. Scrum може не відповідати вашій організації (або вашій команді)
• Знайдіть спонсора в топ-менеджменті

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

Як ми це зробили, це було взяти невелику групу розробників (та аналітиків), щоб скласти пілотну команду SCRUM. Ми дотримувались суворої методології SCRUM близько 4 місяців, після чого компанія розмірковувала над тим, що ми зробили, як ми це зробили, проаналізувала дані (знаєте, усі речі, що БА потрібно робити).

Вони виявили, що пілот мав великий успіх. Тож вони склали ще одну команду, яка стежить за Канбаном, і вони також мали великий успіх. Я думаю, що говорять про те, що решта розробників також формують команди SCRUM / Kanban.

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

Я тренер Agile, і одним із ключових моментів для зміни ініціативи є вхід на всі рівні! Сюди входять керівники, команди розробників, менеджери, тощо. Перш ніж оголосити про великі чи невеликі зусилля щодо зміни, я б запропонував спочатку зустрітись із вами. Зробити це через розмову з третьою особою - це найпростіший спосіб для людей почати хизуватися новими ідеями. Що таке третя особа? Блог, відео на YouTube, презентація, тощо. Таким чином ці люди можуть почати придумувати власні ідеї, і з вашим впливом підскочить на борт із ініціативою змін.

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

Канбан: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI