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

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

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

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

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

Я думаю (і я, можливо, тут виходжу з кінцівки), що ВСІ проекти повинні мати трохи класичного водоспаду: Початковий етап аналізу та специфікації є важливим. Ви повинні знати, що ви робите, і ви повинні мати це в письмовій формі. Отримати вимоги в письмовій формі важко і трудомістко, і це легко зробити погано. Ось чому так багато пропускають це - будь-яке виправдання зробить так: "О, ми робимо спритність, тому нам не потрібно цього робити". Колись, перед спритним, було "о, я справді розумний і знаю, як це вирішити, тому нам не потрібно цього робити". Слова дещо змінилися, але пісня по суті однакова.

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

Як тільки ви знаєте, що вам потрібно зробити - замальовуйте архітектуру. Це частина "отримати велику картину правильно". Тут немає ніякого магічного рішення, немає жодного правильного шляху та жодної методології, яка допоможе вам. Архітектура - це СИНТЕЗ рішення, і вони походять від частково натхненого генія, а частково з важко здобутих знань.

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

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

Коли у вас є ШТО (це ваша специфікація) і ЯК (це архітектура - це дизайн високого рівня), тоді у вас є завдання. Зазвичай їх багато.

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

По дорозі з'являться помилкові сліди, помилки, проблеми, знайдені в специфікації та архітектурі. Це спонукає до таких речей, як: "Ну, все, що тоді планували, було марною тратою часу". Який також бик. Це просто означало, що у вас є менше БЕЗПЛАТІВ, з якими можна боротися пізніше. Якщо у вас виникнуть проблеми з першими на високому рівні, виправте їх.

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

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

Резюме: Вам потрібні всі попередні нудні речі. Використовуйте такі речі, як Agile, як засіб доставки, але ви не можете усунути старомодне мислення, конкретизацію та архітектурний дизайн.

[Ви б серйозно розраховували побудувати 25-поверховий будинок, поставивши на роботу 1000 робітників і наказавши їм сформувати команди для виконання декількох робіт? Без планів. Без структурних розрахунків. Без дизайну чи бачення того, як повинна виглядати будівля. І лише знаючи, що це готель. Ні - не думав.]

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

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

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

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

[наш продукт] був занадто повільним у використанні, баггі, ставав лабіринтно складним і повністю негнучким.

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

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

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

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

Так. Ваші товариші по команді - ідіоти. Ваш проект смоктався через Agile. Почуватися краще? Гаразд, перейдемо далі. : P

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

Agile іноді працює. Цього разу це не працювало для вашої команди. Деякі люди скажуть, що це тому, що ти зробив Агіле неправильно. Зрештою, Agile працює, тож якби ти зробив це правильно, він би спрацював, правда? Що б там не було.

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

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

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

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

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

Якщо ви хочете додати жалюгідну цитату до своїх обговорень, у Ейзенхауера було добре:

"Плани - це нічого; планування - це все".

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

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

+1 Це найкращий опис спритного підприємства, який я читав недавно.

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

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

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

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

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

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

Я схильний використовувати своєрідний гібрид. Загальний план - водоспад, але у виконанні є спритний.

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

У нас однакові проблеми з деяким персоналом.

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

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

Але якщо я розміщую "у вас не вийде робити цікавого і цікавого коду, поки ви не скажете, що збираєтеся будувати, і клієнт не підписався",

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

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

У нашому випадку «великий дизайн наперед» був розбитий на 9 етапів (фактичні випуски) із середнім рівнем 5 підстадій. Дизайнери та розробники йдуть в ногу один з одним, дизайнери перебувають на 1-3 підстанції попереду розробників ... Занадто далеко і відкриття в розробці порушують занадто багато дизайну, занадто близько і змінюються, щоб дизайн коштував стільки, скільки вони були вже впроваджений "встановлений в камені" в рамках розробки. Кожен підетап - 2-4 спринти, які варті 1 розробника.

У менших проектах у нас просто той самий розробник, як спочатку проектувати> виходити> рахунок-фактура> розробляти> виходити> рахунок-фактура ... в циклі.

Проблема іменного тестування

Тестування має багато облич, формально існує близько 7 категорій тестів, кожен з підрозділами ... Один з таких пізніших - «написати автоматизовані тестові одиниці».

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

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

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

Одним із способів змусити їх працювати може бути створення T-Map, що охоплює весь ваш спринт-журнал спринту

У кожної команди є нитка, кожен спринт - це період. Це все пов'язано разом (саме там, здається, ваша команда перевалиться). Закріпіть це десь і отримайте магніти, щоб представити пари / підтеми. Вони навіть можуть «бігти». Але всі знають, де вони та інші команди. Поставте сюди залежності, якщо такі є.

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

У вас є дві проблеми: недостатня форма на вимоги та погана архітектура.

Вимоги

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

У світі водоспадів кінцевою метою є функціональна специфікація, а дорожня карта, як дістатися, - це проект проекту.

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

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

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

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

Архітектура

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

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

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