Позолочене програмне забезпечення
Перший раз, коли я побачив золото, що використовується як опис програмного забезпечення, було в статті Баррі Бума, де він дав наступну першопричину:
Позолота Заздалегідь розроблені технічні вимоги заздалегідь розроблені, як правило, заохочували програмне забезпечення позолоченим. Користувачі, які запитували про їхні вимоги, часто міркували: "Я не знаю, чи знадобиться мені ця функція чи ні, але я можу також вказати її про всяк випадок".
У своєму описі він рекомендує використовувати методи, описані в його дослідженні, включаючи модель життєвого циклу програмного забезпечення спіралі, в рамках якого проекти були розроблені для створення серії прототипів один за цикл, а по мірі збільшення спіралей, повноцінного продукту. Спіраль мала широкий вплив серед дослідників програмного забезпечення та була важливим мостом між водоспадом та Agile. Критичне обмеження спіралі полягає в тому, що щоразу навколо спіралі цикли стають все довші та дорожчі.
Як і у випадку з Agile, спіраль намагається уникнути золотистого покриття, будуючи більш вузький розмір і плануючи проект, який можна виконати досить довго, щоб команди могли виконати вимоги, і в той же час була достатньо короткою, щоб дозволити зосередитися на цілі від першого дня до дня доставки. Один із способів того, що Agile-методи, такі як Scrum, є кращими - це те, що Scrum спринтується протягом певного періоду часу, який не триває більше ітерацій. З статті, здається, управління проектами має більший вплив на покриття золотом, ніж окремі розробники.
Талант для боксу в часі
Вміти поле часу дуже важливо, але це не бінарний навик. У вас його немає або не вистачає. Вам краще чи менш добре з цим. Незалежно від того, чи походить це від вашого начальника чи від вас, я вважаю за краще, якби ніхто не сказав, що ви не можете зупинити золото. Це звучить як особисте, всепроникне та постійне.
Аналіз першопричини може допомогти виявити декілька проблем. Я впевнений, що вони не всі будуть вказувати на вас, і якщо ви не працюєте з психопатами, інші у вашій команді побачать подібні потреби в покращенні набору навичок Agile. Якщо ви знаєте когось без проблем, ви їх не дуже добре знаєте. Якщо ви знаєте когось, хто думає, що їм не потрібно вдосконалюватися, вони не дуже добре знають себе.
Я сподіваюся, що поліпшення, яке ви визначите, будуть речами, які ви зможете вирішити за допомогою власної обізнаності та допомоги колективу. Однак я думаю, що цим не закінчується. Моє сподівання від керівника чи керівника, який пише ваші відгуки, буде, що вони також можуть тренувати своїх підлеглих до успіху. Це особливо важливо, коли організація зазнає революційних змін, таких як перехід від запланованого до Agile (або спеціального на Agile).
Швидкий і брудний або ризикований прототип?
У мене був менеджер, який вимагав виконання завдань певним чином.
Швидке і брудне, але справа краси.
Він знав гнучкість цього, і це було частиною його кривого почуття гумору. Багато людей говорять подібні речі, і вони мертві серйозні. Десь є компроміс чи можливість полегшити проблему за допомогою вдосконаленої технології чи підходу.
Що ми можемо пожертвувати, щоб відповідати нашому часовому вікні?
У першій главі Роз'яснення екстремального програмування , друге видання, Кент Бек розповідає про те, що потрібно швидко рухатись. Його відповідь полягає в тому, що "ви робите лише те, що вам потрібно зробити, щоб створити цінність для замовника".
Ризик
У першому виданні цієї ж книги Бек трохи більш тісно ототожнює погляди Бома на контроль ризику як критичні для його методології, кажучи:
"Ризик - основна проблема розробки програмного забезпечення"
В обох виданнях Бек перераховує та описує вісім поширених ризиків, за якими слідує твердження, що XP (або, можливо, розширення, Agile) вирішує кожен конкретно. Для мене більшість його пояснень зводиться до використання менших кроків, а більш швидкі ітерації дозволяють нам повертати речі на курс до того, як ризики не завищують.
Психічність достатності
Бек обговорює ресурси в контексті розповіді про гірських людей та лісових людей та вводить концепцію, що називається "менталітет достатності". У контексті вашої ситуації він запитує: "Як би ви це зробили, якби у вас було достатньо часу?" Саме ця перша глава, доступна як попередній перегляд книг, може забезпечити багато їжі для роздумів про те, як XP (та інші Agile методи) думають про обмеження, як час.
Примус може бути симптомом, а не хворобою
Роки тому я переглянув книгу про зволікання, де говорилося, що багато зволікань зароджується в страху. Якщо ви не почнете, ви не помилитесь, і, можливо, вас не будуть критикувати. Примушеність і перфекціонізм дає щось таке, про що, як говорить наш моральний сенс, краще, ніж зволікання, але, мабуть, має той же результат. Подумайте, що, можливо, у вас виникає проблема із зволіканням в іншій формі?
Критика та конкуренція
У методах Agile, таких як Scrum, можливості піддаватися критиці чи покаранню за зволікання ніколи не були вищими. Це порочний цикл. Я зволікаю через те, що мене критикують, я критикую, тому що я зволікаю. Щоденні зустрічі з обговореннями ми завжди готові до готовності, тому що ми завжди щонайменше день чи менше, ніж повідомляти команді про те, що ми досягли.
В ідеальній команді Scrum щодня дає можливість виправити зволікання. Помилки не повинні встигнути збільшитися до того, як допомога надійде. Команди не завжди там, де їм слід довіряти, тому лідерам в команді, можливо, потрібно буде активно звертатися або з критикою, або з побоюванням критики, щоб дозволити речам рухатися вперед.
У нашому світі роботи кожна людина в команді також повинна конкурувати з іншими. Трохи шизофренічно вірити в те, що є команда, яка ділиться роботою та славою за досягнення, але потім використовувати щорічний процес управління продуктивністю, який винагороджує 20% своїх членів, карає або виганяє 10% або більше членів, і робить вигляд, що більшість 70% робить все можливе без стимулів. Я думаю, що це великий слон у приміщенні WRT, що пропагує командну роботу, і для посилання на історію Кента Бека це свідчить про глибокі культурні зв’язки із тим, що є гірськими людьми.
Шлях вперед
Як член Agile команди, було б добре вивчити та спілкуватися з іншими щодо того, що працює. Якщо ваша команда використовує TDD для автоматизації тестування своїх підрозділів за допомогою інструменту, знайдіть людину, яка робить це найкраще, щоб ви навчали вас. Якщо у вашого керівника чи менеджера є проблеми з підходом до документації, з’ясуйте, що йому подобається чи хто робить це так, як йому подобається, і дотримуйтесь їх підходу. Якщо вона зводиться до сировинної швидкості кодування, вивчіть, що потрібно для швидшого кодування.
Лідери можуть робити кроки в правильному напрямку, роблячи моделювання бажаної поведінки, як відверта розмова про власні проблеми (а не чужі), пропонуючи та слідкуючи за допомогою діалогу про те, як команда може перейти на стиль Agile Marine (тобто немає чоловіка залишити). Не всі в команді мають однакові здібності. Може бути доречним вивчити парування членів групи або призначення завдань і ролей, які можуть підкреслювати взаємодоповнюючі сили людей, які беруть участь у цьому. Планування зростання або відновлення навичок повинно бути корисною частиною роботи як для керівника, так і для підлеглого, але повинно відбуватися рано і часто бути ефективним.