Як змусити менеджера зрозуміти Agile?


12

У мене проблеми зі старшим директором, який не розуміє ітеративного розвитку (тим більше, спритного). Він наполягає на тому, щоб наша специфікація програмного забезпечення (SDS) була заповнена до того, як буде написано будь-який рядок коду. За його словами, це означає, що вся функціональна деталь є. Також, будучи колишнім програмістом Cobol, він хоче бачити "модулі" та блок-схеми. Це веб-додаток Java для голосного плачу!

У всякому разі, я намагаюся знайти просте місце, щоб обережно вказати на нього, щоб показати, що SDS не повинен бути на 100% повним, перш ніж ми почнемо кодування (і не може бути повним). Будь-які пропозиції?

Дякую!


Що означає SDS? Спробував гуглити, але отримайте багато втручання.
Макс

2
SDS - "Специфікація дизайну програмного забезпечення". Він також використовує цю фразу раніше у публікації.
Томас Оуенс

2
Блок-схеми? Серйозно ?? Біжи! Біжи і не озирайся!
nikie

2
Нічого поганого в блок-схемі, що ілюструє, як працює алгоритм, можна прочитати набагато простіше, ніж псевдо-код.
Bjarke Freund-Hansen

Відповіді:


20

Як консультант, я розумію одне просте правило консалтингу:

  • Ви не можете допомогти людям, які не хочуть, щоб їм допомогли.

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

Як тренер я впроваджую Agile з трьома правилами:

  1. Зібрати всі вимоги на початку проекту неможливо.

  2. Які б вимоги ви не зібрали, гарантовано зміниться.

  3. Зробити завжди буде більше, ніж дозволять час і гроші.

і одна мета:

  • Щотижня пропонуйте щось цінне.

Це все, що потрібно для початку.

Переконати свого менеджера - інша річ.


11

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

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


"Експериментальний" підхід - це те, що зараз працює моя група з одним із наших нових творів. Здається, це працює досі - 3 повторення, всі, хто поза нашою групою, щасливі; розробники тим більше.
DaveE

5

Ви цього не робите

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

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

Якщо він вважає, що це його рішення, то він підриває авторитет ІТ-менеджера, менеджера проектів, ІТ-архітектора, керівництва команди та команди розвитку. Тож він повинен написати програму @ # $% ing сам або STFU і дозволити професіоналам виконувати свою роботу, не обтяжених мозками динозаврів.

Я не жартую. Якщо він не може довіряти тобі робити свою роботу, він повинен робити це сам, і ти повинен тікати криком .


4

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

Потім знову він менеджер, так що, за його словами:

"Нам потрібно використовувати нашу синергетичну гнучкість, щоб створити своєчасне рішення про повне обслуговування"


3
+1 для "Нам потрібно використовувати нашу синергетичну гнучкість, щоб створити своєчасне рішення про повний сервіс"
CaffGeek

Чи справді люди більше знайомі з фільмом, ніж із створенням програмного забезпечення? Або ви відганяли від "старшого директора"?
Алекс Фейнман

2

Старе прислів’я застосовується: Ви можете взяти коня до води, але ви не можете змусити його пити.

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

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

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

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


2

Найпростішим місцем може стати Маніфест про гнучку розробку програмного забезпечення .

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

Це

  • Індивіди та взаємодія над процесами та інструментами
  • Працює програмне забезпечення над всеосяжною документацією
  • Співпраця з клієнтами щодо укладання договорів
  • Відповідаючи на зміни протягом наступного плану

Але, будь ласка, перегляньте сторінку детально, щоб отримати повний намір.


1
і, можливо, важливіше зрозуміти: halfarsedagilemanifesto.org
gbjbaanb,

1

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


5
Менеджер: "Ми вже закінчили?
Чудово

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

-1

Це може допомогти - http://www.youtube.com/watch?v=4u5N00ApR_k

У цьому фільмі "Я хочу запустити спритний проект" ми слідкуємо за досвідом одного такого сміливого керівника проекту, Луки, оскільки він має багато різних зустрічей по всьому підприємству, працюючи над створенням та реалізацією свого "Agile" проекту.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.