Як ми познайомилися з Agile & Scrum

Введення

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



Передісторія, з чого все почалося, як прийшли до того, що потрібен Scrum

Я працюю керівником IT-відділу (менеджером проектів) в одній маленькій/середньої томської фірмі. Чисельність працівників в IT-відділі на початок діяльності: 5 осіб, на даний момент: 24 людини.

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

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

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

Як все було до Scrum

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

Завдання ставилися в redmine, по мірі виконання проставлялися годинник а іноді і відсотки виконання, але часто не було ні термінів, ні якихось планів, дуже щастило, якщо хоча б обговорений dead-line.

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

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



Природно все було перенесено і в електронний вигляд: за деякими завданнями зафіксовано в redmine у вигляді feature або epic, за деякими в старому добром Excel, також поставили важливість та приблизні строки виконання завдань. Потім ми приступили до декомпозированию та оцінки завдань з кожним працівником, який буде виконувати завдання. Вийшов набір feature з sub-tasks і оцінкою термінів виконання завдань. Вийшов своєрідний backlog, але з ним далі треба якось працювати, сам по собі він не дає результатів.

Діаграми Гантта

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

Мною були випробувані:
  • Безліч десктопних програм, наприклад: гант-планінг і багато іншого, які можна з легкістю знайти в інтернеті, частина з них були поганої якості, частина платні. Єдина, яку я можу відзначити — Gant Project. Вона досить зручна, дозволяє з легкістю і швидко побудувати потрібні діаграми. Мінуси: із за того що у мене була безкоштовна версію, не дозволяла вивантажити в потрібному форматі і відсутність можливості командної роботи над одним проектом.
  • 1С Бітрікс CRM. На той момент у нас активно впроваджували дану програму на підприємстві. Вона дозволяла будувати діаграми з деякою обмеженістю по функціоналу. Мінуси: перевантаженість по інтерфейсу, відсутність можливості змінювати кольори на діаграмі (мені це дуже не подобалося), знову ж таки, на той момент була відсутня можливість вивантаження в потрібному форматі (зараз вона ніби є). Великий плюс — можливість командної роботи, але нам у відділі it робота в цій програмі не особливо сподобалася.
  • Redmine. Тут все просто — ставиш завдання з термінами, і діаграми самі по собі з'являються. Мінуси: якщо ти будуєш гіпотетичні плани з залученням багатьох розробників і хочеш побачити за планами, що та як, то розробники це все бачать і у них все це починає захаращувати робочий простір і знову ж таки, немає можливості робити гарні кольори.
  • MS Project. Його я на той момент з якоїсь причини втратив, пізніше я його активно використовував і мені все сподобалося, крім труднощі настроювання командної роботи.
  • Мегаплан. Стара CRM-система компанії. Відразу відкинув, було все не зручно.
  • MS Excel. Старий добрий, для деяких планів досі іноді використовую.

Ось так виглядали плани:



У підсумку, потыкавшись з деякими програмами і час від часу змінюючи їх, ми кілька місяців вели проекти з активним використанням діаграми Гантта. Керівництву це все подобалося, вони бачили чіткі і затверджені плани, і, начебто, все влаштовувало, за винятком невеликого АЛЕ (великого).

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

Які потреби були

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

Що розглядав ще

  • Введення жорсткого регламентованого «waterfall», щоб можна було переривати процеси. Але всі такі можливість переривати пересилила у керівництва.
  • Kanban, але як то не особливо пішло далі, точних причин вказати не можу.
  • Варіант: «ну, з богом», але він вже всіх дістав!

Чому Scrum задовольняє потреби

  1. Гнучкість. Практично в будь-який момент можна переглянути пріоритети та запровадити нові features.
  2. Прозорість. Sprint-list у кожного на пошті (у головних дійових осіб) і спочатку я його вішав в кожному кабінеті. Також можна зайти в кабінет зі Scrum-desk і подивитися хто чим займається в даний момент.
  3. Звітність. Демонстрації по закінченню sprint'a, досить хороша процедура, яка дає зрозуміти (в якійсь мірі) що ж вийшло в результаті.
  4. Докладна картина проекту (залежить від ступеня декомпозиції backlog'а). Постійно оновлюється дає якесь бачення проекту, як програмістам, так і керівникам.
  5. Безпека розробників. Розробники в безпеці від втручань ззовні, хоча б під час sprint'a.
  6. Більш детальне проектування/планування. Завдання не береться в sprint поки вона повністю не зрозуміла розробниками, або влаштовується міні sprint — аналітики/проектування.
  7. Постійне, безперервне поліпшення процесів. Feedback після демонстрації ніхто не відміняв. Щоденні наради (мітинги), також дають позитивний приріст по поліпшенню процесів. І ретроспектива: покращимо все, що було погано!

Як доніс до всіх

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

вивчив? Що дивився? Які ресурси? Які книги?

Спілкування з професіоналами

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

Читання статей

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

Читання книг

Книг було переглянуте не багато. Частина з тих, які радили мигцем поглядали, але нічого відрізняється не знаходили і переставали читати. Основний (для себе), я вважаю, «Agile і XP нотатки з передової» її я прочитав три рази, і завжди, коли мені задають питання: «Як дізнатися про Scrum?» — я називаю її. (посилання є в джерелах і посиланнях)

Початок впровадження

Документ з основними заходами

Розписали основні заходи і сформували невеликий список з описом дій, роздали всім працівникам для ознайомлення. На той момент він був, звісно, далекий від досконалості. (посилання є в джерелах і посиланнях)

Карти

Природно потрібно було десь дістати карти для Poker-planning. переглянули в інтернеті ряд магазинів, вартість колоди для чотирьох осіб варіювалася від 1000 рублів до 2000 рублів. Грошей просити у керівництва мені особливо не хотілося, і тому я їх зробив сам. Звичайний папір А4, чорно-білий принтер, ножиці, — от що вийшло:



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

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

Дошка

Наступний важливий етап-це підготовка Scrum-desk, взяв звичайні ватмани, пару А3 і А4, маркери, скотч та ін. І вийшло досить таки непогано:



Що вийшло в результаті підготовки

  • Команда, яка ознайомилася з основними етапами;
  • Підготовлений Redmine, складено список завдань;
  • Підготовлений Poker-planning;
  • Підготовлена Scrum-desk;
  • І купа ентузіазму.


Перший досвід, перший sprint

Backlog

Перший backlog ми будували в MS Excel, розтрощили все, як потрібно на колонки:



Природно, є ще ряд колонок, які не увійшли на малюнок, але це інша історія. Підкреслю, у нас вийшли саме завдання (feature), а не власні бажання (user-story), як це прийнято в Agile. Перший sprint було прийнято рішення зробити двотижневим. Розставили пріоритети, отсортировали, позначили зеленим, що хотілося б взяти на sprint, розставили story-points. Хм, що таке story-point?!

Як довів до відома розробників. Story-point — день

На систему оцінки story-points — ідеальні людино дні, перейти досить складно і незрозуміло для розробників. Як ми пояснювали story-point — це ідеальний восьмигодинний робочий день розробника, коли у нього є все під рукою, ніщо не відволікає його від роботи (вже помітні проблеми, є все і не заважає хм...), він знаходиться в ізольованому від інших приміщенні, де є свіже повітря, їжа, чай/кава, туалет і він продуктивно виконує поставлену задачу, вирішення якої йому цілком ясно. Деякі речі ще додавалися при поясненні новачкам, але вони особливо не мають значення.

Розподіл ролей

У нашій компанії практично немає cross-розробників? є окремі тестувальники і ми розробляємо під різні платформи. Відповідно, ми слабо лягаємо на одне з понять Scrum, як уніфікація працівників. Ми їм знехтували і в першому sprint'е у нас брали участь різні розробники в одній команді.

Планування

Були роздруковані всі features з backlog'а, які повинні були піти в sprint, і ми почали оцінку.

Які дії на плануванні sprint'a нами робилися:

  1. Приліпити всі листочки на дошку.
  2. Оголошуємо мета, до якої потрібно прийти виконавши sprint, на жаль (може бути на щастя, у нас було кілька цілей, єдиної мети не було, так як в плануванні брали участь розробники з різних проектів.
  3. Провідний розробник всім розповідає про кожну функцію окремо.
  4. Якщо виникають питання то вони тут же вирішуються.
  5. Починаємо декомпозировать кожну feature на subtasks і знову ж пояснювати чому саме так, а не інакше.
  6. Якщо всі завдання декомпозованих і зрозумілі, починаємо оцінку за допомогою Poker-planning.
  7. Називається одна sub-task, і роз'яснюється ще раз, якщо комусь не зрозуміло.
  8. Всі розробники, які компетентні виконувати дану задачу (найчастіше, практично всі), викладають карти сорочкою вгору на стіл з цифрою, яка дорівнює story-points на виконання даного завдання.
  9. Після того, як все виклали карти, перевертаємо карти.
  10. Якщо є сильні розбіжності, то розробник, який виклав оцінку розходиться з іншими, пояснює іншим, чому виникла дана оцінка. Якщо він чогось не зрозумів, то йому ще раз все пояснюють. Далі, переоцінка.
  11. Якщо немає сильних розбіжностей, то оцінюваної sub-task присвоюється значення, яке їй присвоїли розробники.
  12. Таким чином оцінюються всі sub-tasks, із сум sub-tasks складається оцінка feature.
  13. Якщо оцінки features сильно розходяться з попередньою оцінкою, потрібно пізніше вжити заходів.
  14. Набираємо features на sprint. Для першого sprint'a ми встановили, що наші розробники можуть виконувати приблизно сім story-points у двотижневий sprint. Відповідно, якщо їх п'ять, то можна взяти завдань на 35 story-points. Ми взяли більше — 39, як пізніше виявилося, це було помилкою.
  15. Вивішуємо взяті features на Scrum-desk.
  16. Призначаємо час щоденних планерок (мітингів), дату і час демонстрації.
  17. Починаємо роботу.
Перша планерка пройшла вдало, зайняла приблизно 4 години за участю 5-6 чоловік. Природно (як виявилося для нас), взяли в sprint далеко не все, що планували спочатку. На планерці частину часу був директор, і йому та команді даний захід дуже сподобалося, і команда з завзяттям приступила до виконання features.

Склали Scrum-list (MS Word):

(посилання є в джерелах і посиланнях)
  • Обов'язково назву sprint'а і команди.
  • Позначена мета, основне завдання команди, виконати мету.
  • Backlog sprint'а — features, які повинні бути виконані для досягнення мети. В дужках оцінка story-points. Ті ж завдання висять і на Scrum-desk.
  • Означені терміни sprint'a, а також час і місце щоденних планерок (мітингів) і демонстрації.
  • Перерахування членів команди, у дужках відсоткова зайнятість в даному sprint'е, якщо нічого немає, значить 100%.
Спочатку, я роздруковував даний лист і розвішував його в кожному кабінеті, а також розсилав поштою основним дійовим особам. Але пізніше з'ясувалося, що це лише трата паперу і це особливо нікому не потрібно, вистачало одного листа (надалі більше, коли стало більше it кабінетів) в кабінеті розробників.

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

Щоденні наради

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

Дошка завдань в паперовому вигляді

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



Спочатку стікери просто прилягали на дошку, але згодом стали їх додатково закріплювати на скотч, було кілька прецедентів, коли всі злітало. Пізніше з'явилося ще кілька стовпців типу: testing in, code review і т. п.

Навіщо потрібна burn-down?

Burn-down потрібна для того, щоб можна було відслідковувати прогрес виконання sprint'а у команди, а також для того, щоб у візуальному вигляді можна було бачити відхилення від виконання плану по часу. Основна мета burn-down: показати команді (так як у нас самоорганізуються команди), що потрібно прийняти оперативні заходи, якщо відбулося відхилення.

Як будувати burn-down?

Безліч інструментів дозволяють будувати burn-down діаграми в електронному вигляді, ми скористалися MS Excel, а також будували на ватмані.
Спочатку (пізніше з'являлися додаткові стовпці) наша таблиця містила:
  • Перший стовпець — це дати починаючи з першого робочого дня за останній робочий день sprint'a.
  • Другий стовпець — Скільки залишилося спалити story-points. Кожен день під час наради з'являється значення.
  • Третій стовпець — еталон ідеального спалювання story-points командою під час sprint'a, Ідеально спалювати в день = Кількість story-points взятих на sprint/ число днів.
На жаль в паперовому вигляді не збереглася, нещодавно була глобальна прибирання, весь непотріб викинули.
В електронному вигляді робили за допомогою MS Excel:



Як видно з діаграми — перший sprint пройшов практично вдало, невеликі відхилення від ідеального виконання. , як правило свідчить: Якщо по закінченню sprint'a є не спалені story-points, то sprint провалений. На це правило, на той момент, ми закрили очі і раділи успішному завершенню sprint'a!

Демонстрація

Настав час продемонструвати керівництву результати sprint'a. «Команда» (менеджер) підготувала свою презентацію, в подальшому кожен член команди робив свою частину. Спочатку не було стандарту презентації. Зібралося багато глядачів: керівництво, частина відділу продажів і маркетингу.

Презентацію робили в MS Powerpoint:



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

Де і як проходила демонстрація

Так як у нас, на той момент, не було conference-room презентація проходила в кабінеті розробників, дістали проектор і світили на стіну.
Спочатку виступив менеджер (я) розповів для чого всі тут зібралися, розповів основні цілі та завдання sprint'a, і почали виступати по черзі розробники, що завершилось виступом менеджера з демонстрацією burn-down діаграми і питаннями з боку публіки.

Основні завдання менеджера на демо:

  • Ввести всіх в задачі і цілі sprint'a;
  • Фіксувати всі питання та пропозиції під час виступу розробників;
  • Відповідати на питання, допомагаючи розробнику;
  • Фіксувати всі недоліки/позитивні сторони у виступі розробників;
  • Підвести підсумок sprinta з демонстрацією burn-down;
  • Зафіксувати і відповісти на всі питання по закінченню презентації;
  • Отримати feedback.


Розробники на першій демо

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

Публіка на демо

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

Ретроспектива

Перший sprint пройшов вдало і для розробників. Відгуки були тільки позитивні.
Які вдосконалення були обговорені на першій ретроспективі:
  • Потрібно робити більше слайдів у презентацие;
  • Не кликати на демонстрацію людей, які побічно відносяться до проекту;
  • Деякі технічні тонкощі щодо поліпшення устаткування працівників;
  • Більш детально обговорювати features на плануванні, по ходу sprint'a з'ясувалися деякі нюанси, які не були враховані.

Feedback від керівництва

Все сподобалося, потрібно більше слайдів у презентацие. Керівництво захотіло прив'язувати преміальну частину ЗП розробників до результатів демонстрації sprint'a: зацікавлені особи проставляють суб'єктивні оцінки кожному розробнику з проставленням критеріїв цієї оцінки, оцінка менеджера — середнє арифметичне з усіх оцінок. Дана система не особливо прижилася, але це вже зовсім інша історія.

Як все пішло

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

Які заходи вжили

Об'єднання команд, чому сталося

Спочатку у нас було дві команди різного профілю розробки, у кожної був власний Scrum c блекджеком і Scrum-desk. Але так як у нас завжди, і зараз, є просадки з менеджментом (я фактично один), то у мене не вистачало часу на організацію процесів з планування/ведення/демонстрації на дві команди. З цієї причини нами було прийнято рішення об'єднати команди в одну.
Так, — це допомогло виграти деякий час, але, Ні, це не дало позитивних результатів. Таке тривало чотири sprint'a, але так як у команд був абсолютно різний профіль розробки, розробникам було зовсім нема чого працювати разом.

Поділ команд

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

Варіювання часу sprint'ів

Спробували різні варіації:
  • Двотижневий sprint. Оптимальне співвідношення робіт по розробці і робіт з планування. Але є певний мінус, — за часовий проміжок у два тижні з'являються додаткові (smart або термінові завдання від керівництва) завдання, які нам доводиться робити, з цієї причини не завжди sprint закінчується вдало.
  • Тижневий sprint. Співвідношення більше в бік робіт з планування. Але сторонніх завдань майже немає, всі sprint'и закінчуються успішно.
  • Чотиритижневий sprint. Виходять дуже сильні відхилення в результатах sprint'a. Самий невдалий для нас sprint.
У результаті ми зупинилися на двотижневих sprint'ах.

Перейшли на дошку з маркерами

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



І вирішує проблему з отрыванием скотча від паперу. Але, з'явилася нова проблема — клей на дошці. Також зникла burn-down діаграма у паперовому вигляді, так як я почав виводити зображення діаграми на телевізор в кабінеті розробників.

Наступний етап: стали писати щоденні таблиці мітингів маркерами на дошці:



Таблиця містить: число, стовпець спалювання завдань з плану, стовпець спалювання завдань з плану.

Перейшли на хмарне рішення: google doc

Відмовилися від продуктів MS, перейшли в хмарне рішення google doc. Також була модернізована Scrum/Sprint -list. Основне відміну від першого варіанта листа: завдання розбиті по кожному працівнику і вони декомпозованих. (посилання є в джерелах і посиланнях)

Стали вести burn-down діаграми в google таблицях. З плином часу стали додаватися ще значення в таблицю:



Так як при тривалому sprint'e у нас з'явилася тенденція не укладатися в sprint (запаси пробували брати, ні до чого хорошого не привело, ввели нове значення — off-plan, яке показує графік з урахуванням спалювання не запланованих завдань.

Далі пішли ще далі, ввели ще три значення: Real, Off-plan (error) і Off-plan (extra):



Графіки відображають:
  • Ideally. Як і зазвичай — то як потрібно спалювати.
  • Plan. То як спалюються заплановані завдання.
  • Off-plan (error). То як спалюються заплановані завдання і задачі, які не були враховані в плані, — помилки при плануванні.
  • Off-plan (extra). То як спалюються заплановані завдання і завдання, які не відносяться до завдань sprint'a (smart і прийшли від керівництва).
  • Real. То як спалюються завдання реально = план + помилки + екстра.


Перейшли в google презентації

Зручне рішення, можна працювати всім одночасно:



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

Спробували плагін для Redmine

Поставили плагін для Redmine, його назва — Backlog's. Дає можливість організовувати роботу з backlog'го продукту і sprint'ами через Redmine:



У даного плагіна є електронна дошка завдань, яка повністю повторює функціонал тій, яка у нас була спочатку в реальному вигляді. Всі стовпці підхоплюються з Redmine — це значення статусу завдання. Sprint заміщує значення і функціонал «версії» у Redmine.
Досить зручний плагін, ми його використовуємо і зараз.

Ввели регалиеметр





Відображає сумарно спалені story-points кожного працівника за все sprint'и. Стимулює працівників працювати більш продуктивно, кожен працівник здатний брати на sprint певну кількість story-ponts. Бачачи, що інші хлопці працюють продуктивніше нього, працівник робить спроби, щоб досягти більш високих результатів. У нас середня кількість story-points на двотижневий sprint — це сім.

Які поліпшення дали нововведення

В першу чергу всі нововведення спрямовані на поліпшення продуктивності і скорочення часу на планування та супутні роботи. Перехід у хмару і на повністю електронну роботу значно скоротив час на роботи з планування.

Що ж відбувається зараз?

На даний момент існує проблема: кількість працівників велике для одного менеджера і ми не встигаємо проводити всі роботи з планування. Що робити з цим ми знаємо. Намагаємося діяти за напрацьованою схемою.

Дало результати?

Придумана і впроваджена система дає наступні результати:

  • Загальнодоступність матеріалів по роботі команд.
  • Швидкі умови для планування нових sprint'ів, весь backlog вже міститься в системі і він в реальному часі переглядається.
  • Легко і швидко призначати заплановані завдання на працівників, так як вони вже в системі і тільки потрібно призначити виконавця.
  • Стимуляція працівників до збільшення продуктивності роботи (регалиеметр далеко не єдиний інструмент).
  • Простота роботи з документацією, так як все в хмарі.
  • Простота контролю робіт, знову ж таки, все в системі.

Що плануємо робити далі

В даний момент у нас, знову, активно впроваджується 1С Бітрікс, керівництво хоче щоб усі працівники були в одній системі. Плануємо вивчати новий інструментарій і дивитися, як нашу роботу можна перенести в CRM. На даний момент є дещо на прикметі: дошка для Битрикса — scrumban.ru. (посилання є в джерелах і посиланнях)
Є плани за допомогою MS Project застосовувати метод освоєного обсягу в паралелі до всієї нашої системи.

Висновок

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

Джерела та посилання:
Книга: «Scrum і XP: нотатки з передової»
Agile-маніфест
Документ з основними заходами
Scrum-list (перший )
Посилання на магазин, де купити Poker planning
Scrum-list по закінченню часу
Дошка для Битрикса
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.