Оригінальна стаття – Sixty Software Development Pearls of Wisdom
(статтю переклав Вільчавський Іван, редагувала Серебрянська Олександра)
Вбирайте знання з чужого досвіду замість того, щоб повільно підніматися по кожній болючій кривій навчання самостійно
Будь-кому, хто не може правдиво сказати: «Я сьогодні створюю програмне забезпечення, настільки якісне, наскільки це можливо», було б корисно навчитися кращим способам роботи. Досвід – це найкраща форма навчання, яка підходить кожному. Це також найповільніший і найболючіший спосіб навчання. Ми можемо скоротити наші криві навчання, поглинаючи уроки, поради та підказки від людей, які вже отримали, застосували та підтвердили свої знання.
Свій перший курс програмування я пройшов у коледжі в 1970 році. Протягом останніх півстоліття я витратив багато часу, займаючись програмним забезпеченням: вимогами, дизайном, користувацьким досвідом, кодуванням, тестуванням, управлінням проектами, написанням документації, керівництвом щодо вдосконалення процесів, консалтингом, навчанням та написанням восьми книг та багатьох статей. Плюс, звичайно, я сам є користувачем незліченних додатків. За цей час я накопичив численні уроки про бізнес з розробки програмного забезпечення, як зі свого особистого досвіду, так і з досвіду багатьох клієнтів-консультантів та студентів, з якими я працював.
Тут я пропоную шістдесят уроків зі своєї книги «Перлини розробки програмного забезпечення: уроки п’ятдесятирічного досвіду роботи з програмним забезпеченням». Ці уроки стосуються всіх ваших проектів, незалежно від вашої ролі, галузі, технологій чи методології. Уроки поділяються на шість областей, які є ключовими для успіху проекту: вимоги, дизайн, управління проектами, культура та командна робота, якість та вдосконалення процесів. Сподіваюся, ви знайдете їх такими ж корисними, як і я.
Вимоги
#1. Якщо ви не правильно зрозуміли вимоги, не має значення, наскільки добре ви виконаєте решту проекту. Якщо ваш продукт не базується на правильних вимогах, зібраних у потрібних людей, він, швидше за все, не зможе досягти успіху.
#2. Ключовими результатами розробки вимог є спільне бачення та розуміння. Документ або електронна таблиця з вимогами, база даних в інструменті управління вимогами, стек індексних карток, набір приймальних тестів (acceptance tests) або стіна, покрита стікерами , є видимим результатом розробки вимог, але не визначальним результатом.
#3. Ніде більше, ніж у вимогах, не перетинаються інтереси всіх зацікавлених сторін проекту. Визначення та виконання всіх вимог та обмежень, які мають ключові зацікавлені сторони, є ключем до успіху.
#4. Користувацько-орієнтований підхід до вимог буде відповідати потребам клієнтів краще, ніж функціонально-орієнтований підхід. Мислення, орієнтоване на використання, гарантує, що система буде містити функції, необхідні користувачам, без створення надмірної функціональності, яка не буде використовуватися.
#5. Розробка вимог вимагає ітеративності. Прототипування, моделювання, поступове уточнення деталей вимог та поступова розробка допомагають перетворити концепції початкових вимог у глибше розуміння, яке служить основою для проектування та побудови системи.
#6. Гнучкі вимоги не відрізняються від інших вимог. Розробникам потрібна однакова інформація, щоб правильно реалізувати правильний функціонал незалежно від того, який життєвий цикл розробки або процес управління використовує проект.
#7. Витрати на фіксування знань невеликі в порівнянні з витратами на придбання знань. Написання вимог не є важкою частиною. Важка частина – з’ясувати, що являють собою вимоги. Запис знань про вимоги – це, перш за все, транскрипція в якусь стійку форму групової пам’яті.
#8. Головною метою розробки вимог є чітка та ефективна комунікація. Якісна розробка програмного забезпечення базується на якісних вимогах, що виявлені у потрібних людей, зафіксовані в придатних для використання формах та чітко донесені до всіх, хто має бути обізнаний.
#9. Вимоги до якості знаходяться в очах того, хто дивиться. Вимоги мають кілька аудиторій. Якщо люди в цих аудиторіях знаходять проблеми з моїми вимогами, не має значення, наскільки вони хороші, на мою думку.
#10. Вимоги повинні бути достатньо хорошими, щоб дозволити будувати систему при прийнятному рівні ризику. Ризиком, якого слід уникати, є виконання надмірної незапланованої переробки через проблеми з вимогами.
#11. Люди не просто збирають вимоги. Виявлення вимог – це спільний процес, який включає збір, відкриття та винахід.
#12. Виявлення вимог повинно наближати голос замовника до вуха розробника. Ключові представники користувачів — продуктові чемпіони (product champions) — можуть співпрацювати з бізнес-аналітиками, продакт менеджерами або власниками продуктів (product owners), щоб подолати розрив між клієнтом та розробниками.
#13. Двома загальновживаними техніками виявлення вимог є телепатія та ясновидіння. Вони не працюють. Неявні і засновані на припущеннях вимоги не мають бути реалізовані в продукті.
#14. Велика група людей не може погодитися вийти з палаючої кімнати, не кажучи вже про те, щоб домовитися про те, як саме сформулювати якусь вимогу. Семінари з обговорення вимог, як і інші групові заходи, рухаються набагато швидше з меншими командами учасників.
#15. Вирішуючи, які функції включити, уникайте розстановки пріоритетів на підставі думки найвпливовішої особи. Найгучніший або політично найпотужніший голос у кімнаті не обов’язково вимагає найважливіших можливостей системи з точки зору бізнесу.
#16. Без задокументованого та узгодженого обсягу робіт проекту, як дізнатися, чи вийшли ви за його межі? Зміни вимог відбуватимуться завжди, хоча надмірна кількість таких змін говорить про те, що на початку ніхто адекватно не розумів проблему.
До теми: Історії користувача vs. Історії роботи (User vs. Job Stories)
Проект
#17. Дизайн вимагає ітеративності. Завжди існує більше одного дизайнерського рішення для програмної проблеми, і рідко є єдине і найкраще. Перший дизайнерський підхід, який ви задумали, не буде найкращим варіантом.
#18. Дешевше ітерувати на більш високих рівнях абстракції. Створювати та змінювати візуалізовані моделі дизайну швидше та простіше, ніж виконуваний код.
#19. Зробіть продукти простими у використанні правильно і важкими у використанні неправильно. Хороші конструкції ускладнюють або унеможливлюють помилку користувача, і вони полегшують користувачеві шлях до відновлення після помилки.
#20. Ви не можете оптимізувати всі бажані атрибути якості. Як і у випадку з функціональністю, нефункціональні вимоги повинні бути пріоритезовані. Дизайнери мають знайти золоту середину між цінністю від досягнення якихось якісних характеристик в продукті та витратами на їх досягнення.
#21. Унція дизайну коштує фунта перекодування. Накопичення технічного боргу, коли команда не має часу на належне проектування та впровадження, просто відсуває проблему якості в майбутнє, де вона продовжує зростати.
#22. Багато системних проблем мають місце на інтерфейсах. Добре продумана система буде належним чином обробляти винятки, які можуть виникати як на внутрішніх, так і на зовнішніх інтерфейсах.
Управління проектами
#23. Плани робіт повинні враховувати перешкоди. Люди не виконують багато завдань одночасно — вони перемикаються між завданнями. Надмірне перемикання між завданнями сильно погіршує продуктивність.
#24. Не поспішайте давати комусь оцінку. Поспішна оцінка може звучати як прихильність до одержувача інформації. Чим менш чітко окреслено проблему і чим менш певні припущення, тим більш нечіткою буде оцінка.
#25. Айсберги завжди більші, ніж здаються спочатку. Включіть буфери у свої плани на випадок непередбачених ситуацій, оскільки частина роботи в рамках проекту може бути не видимою спочатку, а оцінки часто занадто низькі.
#26. Ви перебуваєте в більш сильній переговорній позиції, коли у вас є дані для обґрунтування вашої думки. Під час захисту ваших оціночних суджень, дані допоможуть вам конкурувати з емоціями, тиском, нереалістичними бажаннями та організаційною силою.
#27. Якщо ви не запишете оцінки і не порівняєте їх з тим, що насправді сталося, ви завжди будете здогадуватися, а не оцінювати. Якщо ви записуєте те, що зробили сьогодні, то завтра це стає історичними даними, які можуть допомогти вам робити кращі оцінки у майбутньому.
#28. Не змінюйте оцінку на основі того, що одержувач інформації хоче почути. Оцінка – це ваш найкращий прогноз на майбутнє з урахуванням певної інформації та припущень. Подобається комусь це передбачення чи ні – це зовсім інша справа.
#29. Залишайтеся осторонь критичного шляху. Щоб скоротити тривалість проекту, потрібно знайти способи як прискорити виконання найбільш критичних завдань.
#30. Завдання або повністю виконано, або воно не виконано: немає часткового виконання. Якщо ви кажете собі або комусь іншому: “Я все закінчив, крім…”, це означає, що ви не закінчили. Відстеження відсотка виконання завдання часто є оманливим.
#31. Команді проекту потрібна гнучкість принаймні щодо одного з п’яти вимірів проекту – обсягу робіт, графіка, бюджету, персоналу та якості. Надмірно обмежений проект, швидше за все, зазнає невдачі, оскільки він не пропонує команді можливості реагувати на зростання, зміни або несподівані події.
#32. Якщо ви не контролюєте ризики свого проекту, вони контролюватимуть вас. Ризики існують, незалежно від того, чи вирішите ви протистояти їм.
#33. Клієнт не завжди правий. Але у замовника завжди є точка зору, яку ми повинні розуміти і поважати.
#34. Ми занадто багато прикидаємось під час розробки програмного забезпечення. Я не завжди у захваті від реальності, але це все, що у мене є, тому я повинен з цим боротися.
Культура та командна робота
#35. Знання не є грою з нульовим результатом. Здорова організація сприяє культурі вільного обміну знаннями та безперервного навчання.
#36. Незалежно від того, який тиск чинять інші, ніколи не беріть на себе зобов’язання, яке, як ви знаєте, не можете виконати. Кожен, хто зобов’язує, залежить від зобов’язаного.
#37. Без навчання та впровадження кращих практик не очікуйте, що продуктивність підвищиться за помахом чарівної палички. Здатність робити більше з меншими витратами вимагає більш здібних людей, більш ефективних практик та інструментів, а також розуміння ваших поточних бар’єрів продуктивності.
#38. Люди багато говорять про свої права, але зворотний бік кожного права – це відповідальність. Обговорення та повага до наших взаємних обов’язків є ключем до ефективної професійної та особистої співпраці.
#39. Невелике фізичне віддалення гальмує спілкування та співпрацю. Співпраця поруч дуже цінна , але ми також повинні бути чутливими до потреби кожного виконувати свою роботу з мінімальними відривами.
#40. Неформальні підходи, які працюють для невеликої колективної команди, погано масштабуються. Чим далі знаходяться роз’єднані члени команди і чим більшою стає команда проекту, тим більш структуровані процеси їм потрібні.
#41. Не варто недооцінювати проблему зміни культури організації, коли вона рухається до нових способів роботи. Ви не можете просто визначити нову політику, методологію чи процес, щоб досягти стійких змін у культурі.
#42. Жодна інженерна чи управлінська техніка не спрацює, якщо ви маєте справу з нерозумними людьми. Щоб переконатися, що ніхто не буде сприйнятий як нерозумний, давайте спробуємо зрозуміти цілі, пріоритети, тиск, драйвери, страхи та обмеження один одного.
Якість
#43. Коли справа доходить до якості програмного забезпечення, ви можете заплатити зараз або заплатити більше пізніше. Чим пізніше в процесі розробки буде знайдена помилка, тим більше коштує її виправити. Завжди.
#44. Цілком природно, що висока якість призводить до більш високої продуктивності. Продуктивність зростає, якщо команда може уникнути виконання надмірної переробки, пов’язаної з недоліками якості.
#45. Організації ніколи не встигають правильно створювати програмне забезпечення, але вони знаходять ресурси, щоб виправити це пізніше. Виконання нашої роботи максимально якісно з першого разу дозволяє уникнути витрат, часу та незадоволення від необхідності перероблювати її.
#46. Пам’ятайте про різницю між гарним і поганим. Часто потрібно небагато додаткового часу, зусиль або роздумів, щоб створити більш якісний продукт.
#47. Ніколи не дозволяйте своєму начальнику або вашому клієнту говорити вам зробити погану роботу. Кожен з нас повинен взяти на себе зобов’язання дотримуватися найкращих професійних практик, які ми знаємо, адаптуючи їх в кожній ситуації, навіть коли на нас тиснуть, щоб зробити щось інше.
#48. Прагніть, щоб ваш колега, а не клієнт, знайшов дефект. Технічні партнерські перевірки (peer reviews) є корисним та ефективним способом виявлення дефектів перед доставкою продукту.
#49. Айтішніки люблять програмні інструменти, але дурень з інструментом – ще більший дурень. Інструмент не допомагає людям, яким не вистачає твердого розуміння методів, які він впроваджує, і того, коли його слід використовувати (або не використовувати).
#50. Сьогоднішній проект “доставити зараз у будь-якому вигляді” – це кошмар завтрашнього обслуговування. Накопичена технічна заборгованість, пов’язана з поспішними рішеннями щодо проектування та розробки, ускладнює вдосконалення та модифікацію систем.
Удосконалення процесу
#51. Слідкуйте за розділом “Управління бізнес-тижнем“. Перш ніж зупинитися на будь-якому новому підході, який обіцяє грандіозні покращення, запитайте себе: «Що вже заважає нам досягти цих кращих результатів?»
#52. Не питайте: “Що в ньому для мене ?” Запитайте: “Що в ньому для нас?” Іноді новий підхід не окупається для кожної людини, а допомагає команді в цілому.
#53. Найкращою мотивацією для зміни способу роботи людей є біль. Щоб заохотити людей брати участь в ініціативі змін, їм потрібно визнати біль, викликаний поточними способами роботи.
#54. Спрямовуючи організацію до нових способів роботи, використовуйте м’який, але невпинний тиск. Тримайте діяльність із покращення та її результати видимими, відстежуйте прогрес і відзначайте успіхи.
#55. У вас немає часу робити кожну помилку, яку до вас вже зробив кожен практикуючий фахівець. Навчіться у тих, хто йшов раніше, щоб вирівняти криві навчання та зменшити помилкові кроки.
#56. Гарне судження і досвід іноді мають перевагу над визначеним процесом. Процес не замінює мислення, але зрозумійте намір, що стоїть за кроком, який ви ставите під сумнів, перш ніж вирішити пропустити його.
#57. Прийміть філософію використання шаблонів документів. Відповідним чином адаптовані шаблони забезпечують узгоджені способи організації інформації та виявлення відсутньої інформації.
#58. Якщо ви не знайдете часу, щоб вчитися та вдосконалюватися, не очікуйте, що наступний проект піде краще, ніж останній. Ретроспективи пропонують потужні можливості навчання, які безпосередньо сприяють вдосконаленню процесів.
#59. Найбільш помітна повторюваність, якої досягла індустрія розробки програмного забезпечення, – це робити одні й ті ж неефективні речі знову і знову. Зберіть набір інструментів «хороших практик», щоб ви могли вибрати найкраще рішення для кожної проблеми, з якою ви стикаєтеся, і постійно підвищувати свою ефективність.
Що робити далі
#60. Не можна змінити все відразу. Однак, якщо ви нічого не зміните в тому, як ви або ваша команда працюєте, у вас немає причин очікувати кращих результатів у наступному проекті. Виберіть найактуальніші питання зі свого списку можливих областей поліпшення і почніть працювати над ними вже завтра. Я серйозно: завтра!
Фото Джоша Хільда на Unsplash