Як Scrum можна адаптувати до волонтерської обстановки?

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

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

Хоча я бачив, як Scrum добре працює для невеликих штатних команд, характер цієї організації різний:

• Члени є добровольцями . Деякі - студенти денної форми навчання. Інші працюють на повній роботі. Ми не можемо очікувати постійного рівня вкладу від когось, оскільки їхнє реальне життя має пріоритет.
• Хоча майже всі мають багаторічний досвід написання програмного забезпечення, не так багато членів зробили це професійно чи в командах.
• Там немає ні Власника продукту . Вимоги до цих проектів визначає комітет. Члени цього комітету також працюватимуть над впровадженням. Це означає, що у нас не буде жодного, відданого власника продукту.
• У нас немає термінів (м'яких або жорстких). Проекти будуть виконані, коли вони завершаться.

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

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

Речі, на які я думаю, що ми могли б отримати користь, від яких не потрібно буде переробити:

• Вимоги Gathering збори (и). Там, де всі сидять за столом і обговорюють Історії користувачів, накреслює макети інтерфейсу користувача та створює реєстр продуктів.
• Спринт- ретроспективи . Це буде для нас цікавим способом сходитись на процесі розвитку, який працює для нас як команди волонтерів.

Про що я не впевнений:

• Як слід ставитися до щоденного прийому ? Цікаво, чи мали би вони взагалі велику цінність у нашому середовищі. Моє розуміння ритуалу стояння полягає в тому, що він допомагає спілкуванню, природно поширюючи інформацію по всій команді. Враховуючи той факт, що наші спринти, ймовірно, доставляють набагато меншу складність, ніж середній спринт, можливо, буде менше необхідності бути в курсі всіх прогресів / розробок інших членів команди.
• Чи варто наполягати на речей XP , таких як Постійна інтеграція, Огляди коду та TDD? Мене хвилює, що проситимуть багато. Мені б більше сподобатися втілити ці концепції у майбутні проекти, як тільки люди більше знайомі з Scrum та працюватимуть як команда.

Мої запитання:

Чи може Scrum бути адаптованим до волонтерського середовища?
І чи мій плановий підхід поки що йде в правильному напрямку?

Загляньте в Канбан. Це більш доцільно, ніж SCRUM для ваших обмежень.

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

Ви все одно отримуєте гнучкі переваги: ​​випускайте в будь-який час, гнучкість, деякий показник передбачуваності - хоча SCRUM може вас трохи просунути в цьому аспекті - і без церемоній чи аспектів SCRUM, які не вписуються у вільну, розподілену команду без будь-яких зобов'язань . Улов? Уривання церемоній вимагає більшої дисципліни, тож СТІЛЬНО потрібно звертати увагу на тести, якість коду, поточну роботу, що триває, та забезпечити достатню розробку вершини відставання (речі, готові взяти людей).

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

(І так, усі ідеї TDD, CI, огляди та програми однорангових програм - хороші ідеї).

Щоб вирішити зазначені вами відмінності, спочатку зазначте:

• Те, що ваші члени є добровольцями, не означає, що ви не можете просити їх взяти на себе зобов’язання. Особливо з відносно короткою тривалістю спринту в Scrum, кожен з членів повинен мати можливість знати, скільки часу вони можуть взяти на себе за проект протягом наступних кількох тижнів. Наявність членів команди доступною за різну кількість часу, кожен спринт зробить планування трохи складніше, оскільки складніше визначити, скільки точок історії реалістичні, але це не робить Scrum нездійсненним.
• Власник продукту несе відповідальність за консолідацію та передачу команді розробників бачення (та вимог), які мають зацікавлені сторони щодо продукту. Консолідуюча частина, ймовірно, вже охоплена керівним комітетом. У частині спілкування вони можуть просто делегувати одного зі своїх членів в якості основного речника. Тоді він з усіх практичних цілей буде власником продукту.
• Відсутність зовнішнього терміну - насправді не проблема для Scrum. Це просто зводиться більше на гордість команди за продукт, щоб його закінчити. Сам Scrum має природний термін для кожного спринту.

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

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

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

Згадані вами практики XP можуть бути запроваджені або не залежними від використання Scrum, а також можуть бути запропоновані під час ретроспективи.

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

Agile - це все про спілкування та співпрацю. Існує причина, чому 2 з 4-х балів в Agile Manifesto говорять про це.

Індивіди та взаємодія над процесами та інструментами

Співпраця з клієнтами щодо узгодження договорів

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

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

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

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

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

1. Зафіксували ітерацію. Щоб ви могли виміряти свій прогрес. Це не лише для менеджменту, а й для того, щоб команда «знала», як вони працюють.
2. Попросіть волонтерів поділитися можливостями на початку ітерації. Вся команда має потребу в тому, що члени здійснюють, інакше певний член може залишити команду для роботи, яка більш професійно виконана.
3. Не маючи терміну, це добре. Scrum не змушує цього, однак, те, що ви робите в кінці кожної ітерації, має бути потенційно доступним. Це дозволить вам вирішити, що робити далі, виходячи з того, що ви зробили до цього часу (що працює).
4. Не маючи власника продукту, це також може працювати. Ви можете мати якусь систему голосування, щоб скласти відставання в рейтингу та прийняти / відхилити виконану роботу.
5. Збір вимог не є частиною Scrum. Ви можете це зробити будь-де, як вам захочеться. Але не включайте це як частину обсягу ітерації. Майте для цього окрему дієздатність. Тож для ітерації плануйте лише ту роботу, для якої чіткі вимоги, наприклад, команда знає критерії прийняття.
6. Ретроспектива хороша. Тож починайте Scrum якомога далі, а потім за допомогою ретроспективи подивіться, що працює, а що ні, наприклад, вам може знадобитися змінити розмір ітерації, можливо, вам потрібно буде позбутися деяких добровольців, які перетягують всіх інших ..
7. Щоденний стан є обов'язковим. Це дає команді можливість синхронізувати один з одним, тобто вони вирівняють свої зусилля, щоб жодне завдання не було зайвим чином заблоковано через відсутність доставки інших членів.
8. XP хороший. Майте чітке визначення зробленого на основі XP, наприклад, жоден код не входить, якщо його не переглянути. Робіть менше, щоб зробити більше ..

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

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

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

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

Я думаю, що Канбан краще підійде для цієї ситуації.

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

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

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