Яка методологія програмування була б нам найкраща?

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

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

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

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

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

• робота, що падає з неба Ці історії ставляться на нижню частину відставання, поки власник продукту та команда зможуть зустрітися, щоб домовитись про його переміщення. Його пріоритет визначається відносно всіх інших зобов'язань вашої команди, і цей пріоритет видно кожному зацікавленому стороні, який зацікавлений подивитися. Потрібно вкрай рідко додати нову функцію посеред спринту, і лише для помилок найвищого пріоритету слід дозволити перервати спринт. Дивовижно, скільки «надзвичайних ситуацій» може чекати до кінця наступного тижня, коли на це чекають регулярні очікування.
• здійснення великих проектів Ви зможете показати, як короткотермінові пріоритети впливають на Ваші довгострокові проекти. Якщо люди постійно переносять історії користувачів перед вашими довгостроковими проектами, це нормально, але для того, щоб прийняти це рішення, всі будуть знати вплив, який воно матиме на графік довгострокового проекту.
• плани проекту розробляються нетехнічними менеджерами. Історії користувачів повинні писатися з нетехнічної точки зору, але ваша команда scrum повинна мати повноваження складати кошториси та визначати деталі впровадження.
• дати жахливо нереалістичні. Ваша команда обробляє всі оцінки, тому що ви самі знаєте, що робите. Якщо ці оцінки неприйнятні для бізнесу, вони повинні вирішити, як розставити пріоритети для функцій. Якщо їм потрібно більше роботи, ніж ви можете впоратися, необхідність наймати більше людей буде чітко видно.
• дати часто пропускають По-перше, ваші оцінки будуть більш реалістичними, що повинно допомогти. Крім того, ви кусаєте дрібні шматки і фактично їх закінчуєте , що допомагає бізнесу відчути, що ви створили щось корисне, навіть якщо не є повноцінним.
• зустрічі, наповнені незручними моментами, Agile має більшу видимість та набагато швидший цикл зворотного зв’язку, при цьому власник продукту активно бере участь. Ваші проблеми з блокуванням та причини затримки не повинні бути сюрпризом.
• також підтримує технічну підтримку На противагу поширеній думці, спритний не несумісний з розділеним графіком. Розгляньте фактори перебоїв у швидкості вашої команди. Якщо ви зазвичай витрачаєте половину свого часу на технічну підтримку, ви просто матимете половину швидкості.

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

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

Скажіть їм ОК, ми будемо рухатися, як це вимагається, серед іншого:

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

Якщо вони не приймають цього, то скажіть їм, що ви не можете рухатися.

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

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

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

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

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

Чи можлива така зміна культури? Так, але у вашому випадку майже точно немає.

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

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

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

подивіться на Extremeprogramming.org - XP - це форма Agile з легко зрозумілими аспектами, які ви можете вибрати та вибрати a la car; дуже гарне місце для початку

зобов'язання замовника не передумувати під час намірів було б гарним початковим місцем для вашого оточення, з його звучання ;-)

Якщо розглянути ландшафт методологій, як традиційних, так і сучасних, можна зрозуміти, що "Agile" - це більше "антиметодологія", ніж методологія. Шаблони мають на меті зобразити «найкращий варіант» даної проблеми в конкретному контексті. Спроби прямо порушити таке рішення чи зразок, як правило, називаються "анти-шаблонами" або гіршими практиками. Так само, хоча справжні методи розробки програмного забезпечення намагаються призначити найкращі практики розробки рішень, "Agile" (Scrum, XP та ін.) Намагаються прямо порушити будь-яку структуру в процесі розробки програмного забезпечення на користь випадкового, хаотичного. підхід - який (пізно) також, здається, вимагає оплесків (наївних) глядачів.

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

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

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

ЗАРАЗ, щоб відповісти на ваше запитання безпосередньо:

З огляду на ваше оточення, я пропоную вам спочатку вибрати Agile-реалізацію (тобто Scrum, XP тощо). Потім налаштуйте підхід відповідно до свого оточення, окреслюючи чіткий процес роботи вашої команди, наприклад:

• Отримання запиту від користувачів;

• Визначити пріоритетні запити користувачів;

• Вплив покращення на існуючу систему (можливо, під час щоденних / тижневих засідань);

• Оцініть час розробки кожного вдосконалення - і повідомте про них різним запитуючим користувачам;

• Виконати фактичні вдосконалення для існуючої системи (тобто кодування).

• Проведіть тестування користувачів - і будьте впевнені від користувачів (наприклад, електронною поштою), що запитувані зміни були успішно виконані.

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

З урахуванням сказаного пам’ятайте, що стара англійська фігура мови, «Як спритний як мавпа», не була вигадана без причин!

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

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

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

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

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

Спочатку я б запропонував зібрати деякі дані. Сядьте в спокійний час і з’ясуйте, що насправді є статус-кво - як все робити. Якщо управління керується реалізацією того, що вони можуть назвати спритним, тоді з’ясуйте щось, що допоможе вашій команді, складіть документ, ляпніть "Agile" на ім'я, і ​​ви готові йти. Майте на увазі, що єдине, що вони насправді знають про спритне, - це слово та певна неясна асоціація зі швидкістю для його звичайного визначення англійською мовою. Отож, я закликаю те, щоб ваша команда виходила перед проблемою, знаходила аромат, який працює для вас, а потім представляє це вашому керівництву як спритний (tm) спосіб. Інакше якийсь PHB збирається забрати книгу і спробувати помістити квадратний кілочок у круглий отвір, і ніхто не буде радий.

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

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

Удачі.

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

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

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

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

Я б рекомендував принаймні прочитати наступне:

• Lean Development Software - Мері та Том Поппендієк
• Agile Software Development - Роберт К. Мартін

і для додаткового кредиту (тому що я думаю, що це чудовий супутник для інших згаданих мною книг):

• Чистий код - Роберт К. Мартін