Процес Agile: як і що слід документувати?

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

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

Коли вони пішли, вони взяли більшість знань і розуміння того, що було розроблено з ними.

Тож у мене є 2 основних питання;

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

Це нормально для спритного чи просто привід для того, щоб не хотіти його писати?

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

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

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

Коротше кажучи:

Команда повинна визначити, скільки необхідної їм документації

Вони знають домен, вони - експерти, і головне, що вони будують річ!

Ось що означає Робота програмного забезпечення над всеосяжною документацією в Agile Manifesto .

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

Хоча я не є експертом Agile будь-якими способами, ось моя спроба відповіді:

1. Чи була історія / вимога із запитом конкретної документації? Якщо ні, то це є частиною проблеми, оскільки ви отримуєте те, що вимагається певною мірою. Це виправдання, і я міг би поцікавитися, що ви тут маєте на увазі під "нормальним". Чи просто більшість тих, хто слідує принципам Agile, робить щось нормальним чи це частина загального процесу, якого слід очікувати? Це два погляди, які я міг бачити за це. EDIT: Я сумніваюся, що більшість команд робить те саме, що стосується документації, але з мого боку це здогад.

2. Кілька посилань, які можуть вас зацікавити, - це найкраще, що я міг зробити з цього приводу:

   • Кращі практики для спритної / худорлявої документації
   • Гнучка та технічна документація

У Agile є певні моменти в маніфесті , де я зазначив би це разом із приміткою:

Працює програмне забезпечення над всеосяжною документацією

Тобто, хоча в елементах праворуч є значення, ми цінуємо предмети зліва більше.

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

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

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

Десь , як мінімум, має бути якийсь опис функцій, історій користувачів та тестів . ІТ може бути у файлах ReadMe в проектах, це може бути в коментарях до вихідного коду, може бути в проектних документах; це може бути все вищезазначене ... або це може бути МВС!

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

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

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