Ефективні способи впровадження спритного на робочому місці?

На ваш досвід (анекдотичний чи інший), які ефективні способи ввести Agile в непривабливу організацію чи компанію?

ОНОВЛЕНО: Чи може хтось говорити у випадках, коли ви намагалися представити Agile, але вас "збили"? Також у вас зараз є ретроспективне розуміння, чому вас "збили"?

ТЕРДО НЕ БЕЗПЕЧНО. Якщо ви не живете в раю. Для конкретних кроків, які ви могли б зробити, я від щирого серця рекомендую забрати копію Безстрашних змін

• Спочатку отримайте підтримку управління . Якщо ви нічого не зробите, цей компенсувати .. Якщо на верхньому рівні все "Термін закінчення вчора ..", "Робочі вихідні протягом наступних 3 місяців", "Чому ви пишете тести, коли вам належить кодування? .. ми можемо перевірити пізніше. " Додо просто не полетить.
• Подивіться, чи підходить культура вашої організації для спритного. Це щось мені не вистачало .. Позичити рядок із книги .. Процес буде простішим-швидшим, якщо культура підтримує та виховує нові ідеї, дає час людям вчитися та робити нові речі, достатньо терплячих, щоб підтримувати інновації з довгострокові вигоди та не вважає неспроможність смертним вироком
• Люди : Визначте новаторів: ранні прийняття: рання більшість: пізня більшість: відставання. Перші 3 - це ваша цільова аудиторія, спочатку .. повинна становити близько 30-40% .., що дає критичну масу для прокатки. Проблема в тому, що Agile вмикає прожектори на слонах у кімнаті .. недоліки та проблеми стають легко помітними .. якщо ви живете в місці, в якому відбувся "вибух Бозо" (цитувати термін Гая Кавасакі) , зміна була б справді повільний і болісний .. якщо взагалі. У нас є тенденція вважати, що якщо ідея хороша, вона буде прийнята. Неправда. Багато соціологічних причин піднімають голову.
• Далі не намагайтеся відразу занадто багато речей. Займай це повільно . Хитрість полягає у використанні підходу, що рефакторинг, який у нас є кодом. Знайдіть маленькі ранки тут і там і обклейте їх гнучким бинтом. Переконайтесь, що люди розуміють практику та переваги, і вони повинні їх прийняти з часом. Не все прилипне, але незабаром стане краще в цілому. Як швидко залежить від ряду змінних, деякі з яких поза вашим контролем.
• Це величезна особиста інвестиція, щоб це відбулося . Перегляньте, чи готові ви взяти на себе це зобов’язання та пройдіться через всі його перельоти. Також вам, можливо, доведеться передати естафету комусь іншому або вище. Будьте готові відмовитись від зміни власності на більшу користь. Не впадайте в синдром "It my baby".
• Agile відрізняється для кожної команди, кожної організації . Не все, що ви читаєте / пропонуєте, буде працювати .. нехай акцепт спрямовує вас до того, що буде працювати для вашого сценарію. Знайдіть інші способи компенсації практик, які не прижилися.

Сподіваюсь, це мало сенс .. як ви могли здогадатися, я вже деякий час займаюся цим :)

Слухайте команду, керівництво, зацікавлені сторони та слухайте підказки. Вони, ймовірно, відчувають біль у ряді областей, до яких Agile безпосередньо звертається.

Дотримуйтесь пропозицій, які можуть безпосередньо полегшити ці болі. "Ви не можете вилікувати те, чого не можете відчути" - так би мовити.

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

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

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

Удачі!

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

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

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

Стискайте їх по горлу, але не помічаючи;)

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

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

Тест-орієнтований розвиток. Демонструючи, як одиничні тести можуть пришвидшити ваш розробник. час, одночасно зробивши код стабільнішим, - це перший перший крок до заповнення спритної Kool-Aid.

Вдосконаліть себе спочатку. Дійсно. Приклад - це сильний спосіб поговорити про спритний. Більше того, як уже говорив хтось, уникайте технічних визначень і просто використовуйте терміни, які менеджери та керівники можуть зрозуміти. Два тижні замість спринту; Планування замість Sprint Планування або Планування Гра; Product Manager замість власника продукту тощо. Мішель Слігер зробила дивовижну презентацію про Agile у водоспаді . Дійсно обов'язково переглянути відео. Можливо, вас також зацікавлять інші відео про спритне усиновлення .

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

З повагою

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

Потім, коли кожен великий проект закінчувався, ми починали наступний, використовуючи спритні спринти в 2 тижні. Весь цей процес зайняв кілька місяців, перш ніж всі були спринтними, але це означало, що менше розладів, і кожен може «полегшити» процес

В команді розробників представлення Agile - це набагато більше, над чим ти маєш певний контроль.

Однак, я бачу, головне питання - це вимога, яку Agile вимагає від постійного зворотного зв’язку від вашого "замовника" або представника замовника.

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

Найкращий спосіб, за який я б сказав, - зосередити увагу на несприятливих перевагах сприйняття процесу Agile та передати їх чітко своєму клієнту. Звичайно, якщо у вашій компанії є сфера продажів / рахунків, те саме стосується і там.

Крок 1. Переконайтесь, що ваш проект має непоганий відставання та переконайтесь, що він надає пріоритет

Крок 2: введіть практику SCRUM (керовані ітерації, щоденні складання, майстер scrum-master, власник продукту, графіки перезавантаження)

Крок 3: Результати кожної ітерації команди при перегоні

потім ...
впроваджуйте TDD / BDD, парне програмування, огляди коду (все дуже обережно), і якщо у вас є достатньо хороша команда, будьте всі розміщені (якщо можливо, командна кімната).

Перш за все, зрозумійте, чи буде спротив (БУДЕ), тому будьте готові керувати цим.

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

Люди завжди стійкі до змін, а перехід до скаму - досить великий. Мотивація та напрямок є ключовими.

Перший крок - мотивація людей, щоб дати шанс скремпу. Я виявив, що Google Tech Talk Кен Швабер був дуже корисним для того, щоб змусити людей усвідомлювати переваги scrum, забезпечуючи гарне знайомство. Почніть з людей, які, на ваш погляд, сприйматимуть зміни, будь то розробники чи менеджери, тож ви зможете побудувати деяку силу. Отримати менеджерів на вашій стороні в певний момент стане необхідністю, але як ви впораєтесь, це залежить від вашого оточення.

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

Після того, як люди вмотивовані та мають уявлення про те, що їм потрібно зробити, вам потрібно провести свою першу зустріч із плануванням та встановити необхідні частини scrummaster, щоденні зустрічі тощо).

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

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

Удачі!

• Продемонструйте успіх - див. Відповідь марки
• Зверніть особливу увагу на принципи / прийоми, які могли б спричинити найбільший вплив у компанії
• Пам'ятайте, що це стосується гнучких принципів, а не контрольного списку

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

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

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

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

1) ви можете почати використовувати scrum у трохи більш пухкій формі для керування наявними робочими чергами негайно. Але загляньте і в Канбан.

2) почніть використовувати scrum у більш суворій формі щодо якогось нового проекту, який потребуватиме інновацій, раннього зворотного зв’язку і де багато чого невідомо. Ви можете підказати власникові / власникові продукту, що scrum ідеально підходить для цього нового проекту.

Але пам’ятайте! справа не лише в коді, власник продукту має важливу роль і повинен розуміти та виконувати свою роль. Це означає, наприклад, не писати всі характеристики спереду, а починати з мінімуму, швидко повторювати, отримувати зворотній зв'язок, вивчати та годувати те, що відбувається назад і так далі. Спробуйте співпрацювати з продуктовим менеджером, який би настільки сильно зацікавився представити Scrum, як і ви, але з боку власника продукту, і в ідеалі він / вона має бути достатньо жорстким, щоб відбивати запити управління та захищати спринт.

Потрібно об'єднати зусилля з розробки та управління продуктами, щоб запровадити scrum.

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

На мій досвід, простіше ввести scrum в чистому вигляді спочатку, а потім полегшити його, щоб отримати більше черг роботи з обслуговування. Важче навпаки.

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

Деякі роки тому я був консультантом дуже великої компанії (майже 20 000 співробітників), яка керувала багатьма великими проектами корпоративного програмного забезпечення. Я був на одному з них. Досить критичний.

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

Я зіткнувся з сильним небажанням, тому на деякий час я кинув цю ідею. Але проблеми продовжували посилюватися, тому ми спонсором лідера команди ми вирішили зробити Scrum все-таки нашимсельвом.

Кожен, включаючи мене, мав будь-який досвід роботи з Scrum. Тож ми відкрили основу, зробивши ...

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

Я думаю, щоб щось ввести у таке підприємство, ви повинні дотримуватися наступних принципів:

• Це потрібно змінити . Якщо немає переконливих причин того, що зміни потрібно здійснити, немає жодної причини, щоб керівні команди створили ризик.

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

• Не слід пропонувати змінити всю організацію одразу . Ви повинні запропонувати пілотний проект, який би ви взяли на себе відповідальність. Я раджу вам поставити реалістичні цілі, такі як значне збільшення видимості щодо того, що відбувається в проекті. Це, IMHO, головний внесок Scrum в управління програмним забезпеченням. Це дозволяє здоровому глузду людини діяти і, таким чином, рухатися вперед.

• Нарешті, обов'язково слід забезпечити, щоб досвідчені люди контролювали цей вступ. Не просто читайте книгу чи дві. Ви повинні пройти тренування, і я б сказав, що досить скористатися досвідченим тренером. Очевидно, це можна зробити і без, але це буде боліти :)

Якщо ви будете слідувати принципам і прийдете з фактами, це спрацює. Про факти ви знайдете багато в книзі Програмне забезпечення за 30 днів: як спритні менеджери перемагають шанси, радують своїх клієнтів і залишають конкурентів у пилу . Це остання книга творців Scrum, Кена Швабера та Джеффа Сазерленда .

У публікації блогу Кена про книгу ви можете прочитати:

Джефф Сазерленд і я це зробили. Ми написали книгу разом, наше перше спільне написання з моменту першої публікації Scrum в 1995 році. Що нас спонукало? Питання, яке нам часто задають:

Як ми продаємо Scrum нашому керівництву?

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

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

[...]

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

Але тоді відділ науково-дослідних та наукових досліджень вирішує, що він просунеться. Йдеться вже не про планування на два місяці до написання коду. Спринти будуть короткими, а поза спринтами ви отримуєте дуже низькі оцінки роздільної здатності, що містяться у відставанні / дорожній карті. R&D розуміє, що вимоги занадто часто змінюються, щоб класичний водоспад був ефективним, але менеджери продуктів хочуть чіткого, продуманого та добре складеного бачення того, як буде виглядати продукт за 12 місяців.

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

На практиці багато наших користувачів, які практикують гнучкі методи, - це створити телескопічний план, який об'єднує довгострокову дорожню карту (або відставання) з управлінням короткотермінових спринтів (або ітерацій). Менеджери все ще бачать приємну, оцінену дорожню карту основних функцій, що очікують на додавання, а розробники просто збільшують масштабніше і вирішують фактичні робочі завдання. Однією з цих переваг є те, що це зменшує кількість "торгувань", які відбуваються, коли менеджери переглядають робочий план. Замість того, щоб команда розробників давала лише дуже приблизні оцінки (наприклад, "4-6 тижнів!"), Вони отримують можливість переглядати кожну конкретну історію користувача та розбивати її на менші шматки. Коли ви це зробите, раптом менше місця для торгів. Ви витрачаєте 10 хвилин, розбиваючи 5-тижневу історію користувача на шматки розміром приблизно 1 день, і раптом аргумент не "ні, ви можете зробити це швидше. ні, ми не можемо. так, ви можете". але "ось що стосується цих зусиль, включаючи всю приховану роботу, яку початкова оцінка не врахувала. Що ви пропонуєте ми усунути? Забезпечення якості? Тестування? Навчання нового хлопця? Створення середовища побудови?".

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

Гаразд, я відчуваю, що це перетворюється на крок продажів, тому я зараз зупинюсь. :)