Представляємо розробку Agile після створення традиційного проекту

Близько півтора років тому я вступив на робоче місце, яке претендувало на розвиток Agile. Я дізнався, що це місце прийняло кілька спритних практик (таких як щоденні складання, планування спринту та огляди спринтів), але жоден із принципів (просто вчасно / достатньо хороший менталітет, викриття невдачі, багате спілкування).

Мені зараз доручено зробити команду більш гнучким, і мене запевнили, що я маю повний внесок від розробників та бізнес-команди. Як пілотна програма, вони дали мені проект, який щойно завершив збір вимог за 15 місяців, має документ на 110 сторінок "Аналіз та дизайн" (який слід вважати "написаним каменем"), і де я не маю доступу до кінця користувачів (лише до комітету, що складається з менеджерів користувачів, які фактично не користуються продуктом).

Я почав з малого, подавши їм список очікуваних результатів для перших 5 спринтів (залишивши майбутні спринти невизначеними), список цілей для першого спринту, і я розібрав доктора A&D, щоб отримати достатньо історій користувачів, щоб досягти цілей першого спринту. .

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

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

Отже, мої запитання:

1. Що я можу зробити, щоб ефективніше запровадити зміни до стійкого бізнесу?
2. Чи існують інші практики, які я можу запровадити на ІТ-стороні, щоб показати бізнесу переваги спритного?
3. Тягар документації задушує нас - бізнес все ще сприймає це як стратегію управління ризиками, а не як ризик. Що ми можемо зробити, щоб полегшити їхні проблеми та вимоги щодо документації (зокрема, кількість документації та їх потреба в усьому)?
4. Ми знаходимося в окремій будівлі від нашого бізнесу, приблизно в 3 кварталах, і вони відмовляються від того, щоб їхні люди спільно проживали проект, а людина "не зможе працювати над іншими проектами, поки вони у нас будівля ». Вони сподіваються, що ми завжди будемо туди перебиратись і збирати свої запитання, щоб ми могли їх задати відразу і не витрачати час цієї людини на «постійні перебої». Що ми можемо зробити, щоб отримати від них багатше спілкування?

Будь-які додаткові поради також будуть вдячні.

Дякую!

Мене запевнили, що я здійснюю повну оплату від розробників та бізнес-команди [...] Я не маю доступу до кінцевих користувачів [...]

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

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

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

"Зробити команду більш спритною" - це не реальна мета. Він недостатньо конкретний, він не вимірюється, він не має кінця. Вам потрібно щось специфічне: ціль, виражена на X відсотків меншою кількістю дефектів, або Y відсотків ваших термінів доставки функцій, фактично виконаних, до дати Z.

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

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

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

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

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

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

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

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

Щодо вашого другого запитання, я настійно пропоную вам принести по одній речі.

Ваша проблема з документацією заслуговує на те, що це власний пост тут на P.SE, і я не бачу жодної проблеми з тим, що ви перебуваєте у двох різних будинках, якщо обидва бажають регулярно зустрітися. Бувають ситуації, коли одна зі сторін взагалі не хоче зустрічатися;)

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

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

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

Це ваша проблема. Вони цього не розуміють. Хтось не може попросити вас бути більш спритними та не бажати їхати разом. У них неправильні очікування. Речі ламаються, на передній план, перш ніж навіть почати. Виправте очікування, інакше ви провалитесь. Це так, як я прошу вас проїхати 150 МПГ, і я даю вам Chevette, в якому це потрібно зробити.

Зробіть час / ресурс / вартість необхідної документації, і дайте їм бачити, наскільки це виштовхує графік.

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