Як зупинити зміну специфікації розвитку в середині розвитку?

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

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

Запитання : Які найкращі способи, які ви знайшли, ви знайшли, щоб мінімізувати та запобігти появі змін специфікацій на середині або після розробки?

Існує відома військова приказка, приписувана Гельмуту фон Молтке: "Жоден план бою не витримає контакту з ворогом". У той же спосіб, я не думаю, що можливо зробити специфікацію, яку не доведеться міняти - хіба що, якщо ви не зможете передбачити майбутнє та прочитати думки зацікавлених сторін (навіть тоді вони, можливо, ще не зробили свою думку, навіть якщо вони стверджують, що зробили). Я б запропонував замість цього підійти до нього декількома способами:

1. Робіть чітке розмежування, що можна змінити, а що не можна. Ясно повідомте це зацікавленим сторонам, змушуйте їх якнайшвидше підписуватись на незмінні речі.
2. Підготуйтеся до зміни заздалегідь. Використовуйте методології коду, які дозволяють легше змінювати змінні частини, вкладайте кошти в налаштування, інкапсуляцію та чіткі протоколи, які дозволять змінювати та замінювати деталі самостійно.
3. Часто спілкуйтесь із зацікавленими сторонами, вимагайте відгуків та схвалення. Це одночасно триматиме вас у синхронізації та уникатиме, щоб вони заявляли "о, це не те, чого ми хотіли", коли вже пізно. Як зазначається в інших відповідях, гнучкі методології та часті міні-релізи допоможуть вам у цьому.
4. Вкладіть у графік час, щоб пристосувати неминучі зміни. Не бійтеся сказати "нам знадобиться більше часу" рано, якщо ви думаєте, що це було б - якщо розклад, який вам дано, нереальний, краще це знати (і вам це потрібно записати) на початку, ніж на кінець.
5. Якщо зміни занадто обширні і загрожують терміном - відштовхуйтесь і скажіть щось на кшталт "ця зміна можлива, але термін підштовхне до X часу, зробіть свій вибір".
6. Створіть формальний процес запиту змін, визначивши їх із пріоритетом та призначивши зміни версій чи версій. Якщо ви можете сказати людям "я не можу цього зробити у цьому випуску, але з радістю викладу це за графіком наступного", це набагато краще, ніж сказати їм "ти запізнився, зміна не може вступити , до побачення ", і зробить їх своїм другом - вони будуть раді вас звільнити вчасно, щоб ви могли швидше потрапити до наступного випуску, який зміниться - а не вашого ворога.

Доставляйте щось (я вагаюся вживати слово що завгодно) рано і часто доставляйте. Тобто - використовувати якусь ітераційну методологію розвитку.

Це основа Agile розробки, але може бути використана (майже) будь-яка методологія.

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

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

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

Ви ОБОВ'ЯЗКОВО знайти якийсь спосіб пристосування змін, як ви йдете! Вони трапляться, тому що більшість зацікавлених сторін, навіть якщо вони кажуть "так, це те, що я хочу", насправді поняття не мають, чого хочуть, поки це не буде перед ними. Ось чому у нас так багато людей, які застосовують ітераційні методи.

Незалежно від того, чи ви переглянете продукт чи будь-що інше, ви ОБОВ'ЯЗКОВО знайти спосіб зміни цих змін, тому що намагатися знайти способи не змінити - це лише коротке прохання самопливу вимкнутись на кілька хвилин, щоб ви могли літати.

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

Ви ставите неправильне запитання. Спеціальні зміни завжди відбудуться в проектах розробки програмного забезпечення будь-якого розміру.

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

Питання, яке вам слід задати, це не "як я можу зафіксувати специфікацію", це "як я можу структурувати свій код і процеси, щоб відповісти на змінне середовище, не викидаючи все, що я вже написав?"

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

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

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

Зміна - це лише сюрприз ... якщо це сюрприз!

Я б запропонував подумати над:

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

Зміна - це природа того, що ми робимо. З якого часу ви кодували алгоритм саме так, як це було передбачено на 1 день?

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

Що ж, хоч дзвінок, клієнти завжди хочуть більше, але ось кілька моментів, про які слід звернути увагу:

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

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

Модульний випуск: випустіть свій код модульним способом, випустіть, протестуйте, отримайте зворотній зв'язок та відпустіть знову.

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

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

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

Активне залучення користувачів протягом циклу розробки та використання якомога більше методів Agile насправді допомагає нам у наших продуктах.

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

Для мене це досить просто.
Скажіть одному, "Власник продукту" , який замовив функції, що це нормально, але він повинен вибрати пару запланованих функцій, на яких він міг би бути без цього терміну.
Подумайте про це як на половину спринтської зустрічі з PO, де ви скажете йому, що спринт не згорятиме до 0.

Пс. Якщо це не "PO", я б сказав, не розмовляйте зі мною через "PO"

Які найкращі способи ви знайшли, хлопці, щоб мінімізувати та запобігти появі змін у специфікаціях на середині або після розвитку?

Немає кращих способів. Керівництво залежить від обмеження змін у специфікації на певній фазі розвитку.

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

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

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

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

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

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

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

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

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

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

Якщо ви мали справу з клієнтом, що платить $, і якщо ви покрили свою дупу, уклавши контракт (http://vimeo.com/22053820?utm_source=swissmiss), то зміни в специфікаціях коштують цьому клієнту більше часу та більше грошей ( або потенційно однаковий або менший час, але експоненціально більше грошей). Ваша компанія намагається піти від зміни специфікації, не вимагаючи більше часу та більше грошей.

Тим часом спроба досягти строків викликає у вас та ваших колег НЕОБХІДНІ стрес; Ви не можете провести якісні вихідні з друзями / родиною. Це справді непотрібно, бо хто кидає на тебе роботу, напевно, навіть не знає цього, що сумно.

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

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

Я ще бачу, як програмісти страйкують, але це було б щось. Некомпетентних менеджерів занадто багато в програмних компаніях. Занадто багато людей хочуть отримати щось дарма, в Craigslist або в реальній компанії. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Програмістам потрібно мати більше кульок.

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