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

Насамперед, коли Замовник звертається з ідеєю Продукта, ми конкретизуємо її, документуючи бізнес-вимоги і контекст. Виходячи з того, що будь-який нетривіальний продукт є, врешті-решт, нетривіальним (інакше для чого тут ми, розробники?), ми далі застосовуємо декомпозицію.

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

• архітектури
• типів користувачів
• моделі даних
• функцій користувача (use-cases)
• інтерфейс користувача (опис екранів та форм, якщо Продукт матиме графічний інтерфейс або буде вебовим)
• опис як все це інтегрується з іншим ПЗ і залізом (включаючи точну версію (версії) ОС, БД та веб серверів, по потребі)
• вимоги по безпеці та конфіденціальності
• вимоги до ліцензійної політики, де документується як Продукт буде розповсюджуватись Замовником і, відповідно, які сторонні компоненти сумістні по ліцензійним міркуванням
• інші вимоги, по потребу

і робимо з кожного пункта добре сформульовану мету.

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

Зазвичай проекти з розробки ПЗ фокусуються на функціональності. Коли вони зосереджені на даних ми звемо їх інакше - розробка БД. Коли вони про інтерфейс користувача, ми кличемо їх дизайн (інтерфейсів). Жоден з цих двох типів проектів не є темою даної статті, тому ми сфокусуємосб на функціях.

Нетривіальна (визначенні див. вище) функціональність ПЗ знову ж таки занадто складна для миттєвої реалізації і ми проводимо декомпозицію далі. Для кожної функції в переліку ми робимо детальну документацію:

• коротку назву
• мета та опис функції
• метод виклику (клік мишою, виклик REST HTTP, виклик функції в вихідному модулі, юніксовий шелл, т.п.)
• потік подій
• тести, що мають задовольняти умову “конкретності” добре сформульованої мети
• тікети, якими ми ділимо розробку функції в одиниці роботи для планування

Кожен набір тестів має перевіряти кожну можливу категорії неправильного вводу і мати щонайменш один приклад правильного вводу.

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

Тут (і тільки тут) починається власне розробка: функціональність вже добре задана, Розробник погодив з Замовником що означає корректна поведінка функції (use tests, Luke!).

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

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

Так, ми приходимо до необхідності автоматичних тестів. Прямо з вимоги конкретності добре сформульованої мети.

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

Так, відстань між просто автоматичними тестами і розробкою, керованою тестами, дуже коротка.

Бонуси при такому підході:

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

.. і т.д. і т.п.

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

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

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

Деякі посилання на нещодавні дописи по TDD і що з нею може піти не так:

1. корисні критерії тестів
2. якості ідеального тесту
3. Багаторівневе тестування
4. Як розробка, керована тестами, може піти хибним шляхом
5. Python dependency injection - метод тестування

English translation

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

Розділяй і володарюй - що може бути простішим?

– Як можна з’їсти слона?
– По шматочках.

Достатньо сказано на цю тему. Завершу двома посиланнями на вікіпедію: Декомпозиція і Парадигма декомпозиції. В цих статтях згадується різниця між об’єктно-орієнтованною та структурною програмною декомпозицією, але це, насправді, несуттєво. Інструмент залишається тим же.

Наступна стаття буде присвячена власне реалізації добре сформульованої мети і декомпозиції в розробці ПЗ.

Paul’s Pontifications » Blog Archive » New Software Technology: Blockage On Line

Every company has a few eccentric engineers who try to explain why this or that new technology would be a great investment. Sometimes they are even right. But they are almost never taken seriously. And so great technologies that could actually save the world a great deal of money on software development (not to mention improve quality a lot as well) languish on the shelf.

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

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

Отже, чи є шлях компанії з оффшорної розробки ПЗ підвищити свою продуктивність не виконуючи наступний вебовий проект в J2EE/ Struts/ Oracle/ що-б-ще-такого-вліпити?

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

1. Майте хорошу службу продажу, виконуйте обіцяне вчасно і вклавшись у бюджет. Низький ризик, мала маржа.
1. Мати хороший продукт. Величезний ризик, величезна маржа (згадайте Skype?)

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

То де ж знайти таких розумних замовників? Читайте допис Пола.

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

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

Ви вирішили іншим шляхом - розробити продукт? Мої поздоровлення, ви схильні до ризику. І ви будете винагороджені. Коли-небуть пізніше. Можливо. Якось. Просто не кладіть всі яйця в один кошик

Варіант англійською.

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

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

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

З чого Ви почнете проект з розробки ПЗ?

І це навіть в найпростішій моделі проекту: один замовник - один розробник…

Ну добре, мої студенти - не зірки МІТ-у або КалТеху, але половина!?..

Проект з розробки ПЗ - це проект. За визначенням
Вікіпедії та PMI це означає, що:

• у нього є початок
• у нього є кінець і
• він пов’язаний зі створеннямcreation of чогось

Іншими словами, у кожного програмного проекта є мета.

То чому ми не використовуємо методи психології, які публічні і давно доступні, як допомогу в цьому процесі досягнення мети?

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

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

Які необхідні компоненти цілі, що можна досягти?

Та це ж елементарно! “Not a rocket science”, пустити гугл шукати “well formed goal” (добре сформульовану мету). На момент написання англійського варіанту цієї статті, гугл видає статтю Вікіпедії”Well formed outcome” третьою.

Основними критеріями добре сформульованої мети є:

1. Позитивність. Це означає що будь-який проект, метою якого є, скажімо, “недопуск спаму і вірусів на комп’ютер” є одразу приреченим на невдачу. Ніхто просто не в стані досягти небуття чого-небуть точно так же як і довести негативне твердження. Для перевірки, доведіть що ви не п’єте коньяк вранці.
2. Конкретність. Це найважливіша властивість хорошої мети в програмному проекті. Знайте що Ви побачите, почуєте, відчуєте коли досягнете мети (наприклад певна функція ПЗ буде працювати корректно). Будьте настільки конкретними, наскільки Ви можете. І навіть більше. Використовуйте всі сенсорні системи для визначення вашої мети. Неконкретність - перша причина зриву в досягненні цілі.
3. Бути можливою і досяжною. Можна вважати, що практично будь-яка (корисна) мета - досяжна. Та на практиці цей критерій насамперед означає, що Ви, той хто прагне досягти цієї мети, вважаєте її можливою та досяжною. Прямо тут і зараз. Цей критерій пов’язаним з наступним:
4. Наявність всіх ресурсів. Майте комп’ютре, майте інтернет-з’єднання, майте електрику та волю для виконання проекту, знайте та умійте те, що треба, якісно спілкуйтесь з Замовником, і т.д., і т.п. Майже будь-що можна вважати ресурсом (включаючи перелік цих критеріїв), що Вам доступен або не доступен. З мого досвіду, недостатні ресурси - друга за частотою причина недосягнення мети.
5. Добре окреслений часовий проміжок. Ні, пане Замовнику це має бути готово на вчора не являється добре окресленим часовим проміжком.
6. Екологічність. Ви, хто працює над досягненням результату, знайте чого він буде коштувати і що за собою потягне. Так, отримати мілліон внаслідок грабунку банку може бути добре сформульованою метою. Але тільки якщо Ви приймаєте ціни та наслідки такої поведінки. Я - ні.

Весь механізм досягнення добре сформульованих цілей забезпечується самою природою. Мозок людини, від кори до спинного мозку налаштований на досягнення цілей. Вся еволюція від бактерії через трилобітів до homo sapiens - це процес успішного досягнення цілей. Ті, хто не досягав мети - зходив з дистанції. Його з’їдали. Так що буквально кожна людина (я не знаю нелюдських розробників ПЗ, якщо вам такі відомі - дайте знати) має всередені виключно потужний механізм досягнення будь-якої мети.

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

То чому б реально не зробити перший крок для досягнення мети - добре її визначити?

Англійський варіант Software Development Basics: Well-Formed Outcome

Mishkin Berteig from Agile Advice follows up and tries to explain. The hypothetical situation is Sarah. Sarah’s bosses want her to work on a different project for a day, to add a feature that would give them a sale. To me, this is a simple cost/benefit analysis. Is the feature (and resulting sale) worth losing a day of Sarah’s work on her current project? If so, get the stakeholders to remove one day of work from the current iteration to compensate. Problem solved.

[...]As an exercise, re-read the two articles, and all the pronouncements about how Sarah spending a day on another project would “stop the whole team” (Berteig’s words), cause the whole iteration to be reset and seriously damage both the business’s trust in the development team and Sarah’s self-worth. Now imagine she instead had to take the day off to care for her sick three-year old son.

Я повністю погоджуюсь з аналізом AgileAdvice. І це не зміниться доти, доки хто-небуть не зможе звести поряд:

• сейлза або Замовника що хоче “всього двогодинну” фічу що “має бути в онлайні вчора”
• Замовника поточного проекту
• розробників.

До цих пір жодного рішення, що вдовольнить всіх, досягти неможливо. Питання: наскільки часто у вас вдовольняються ці умови? У мене - досить рідко.

І, навіть можливість досягнення рішення, не гарантує що воно буде знайдено. Навіть якщо цей сейлз і Замовник поточного проекту - одна і та ж людина. Я на те, що вони домовляться, грошей не поставлю - у мене є такий замовник.
Це трапляється тому, що кожен замовник (включаючи замовника що прямо зараз сплачує твою роботу) інтерпретує будь-які слова сказані (і навіть не сказані) йому як твоє зобов’язання. Навіть якщо було написано тричі 24-м кеглем і жирним шрифтом, що це лише попередня оцінка.
І будьте певні, будь-хто, хто просить тебе втулити “термінову крихітну додаткову опцію всього на дві години” очікує що при цьому всі ваші попередні зобов’язання будуть дотримані. Навіть якщо він каже зворотнє! (Невже хтось очікує, що він скаже своєму боссу/замовнику, що він власноруч відклав проект? Ха! Завжди є розробники, на яких можна ткнути пальцем!)

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

Або явно сказати що нічого на даній ітерації не гарантується.
Якщо хтось думає, що є інше рішення, у мене є для нього крихітний проект “з фіксованими вимогами” І Бруклінський міст на додаток.

Ах да!.. Люди хворіють… Ну да, вони уходять у відпустку, хворіють і їх збиває автобус. Но хіба це специфічне для Agile Development?
Вдалої розробки!

English translation