На російському ринку аутсорс-розробки не так багато компаній, які використовують гнучкі методології розробки (Agile). Всім звична робота по каскадної моделі (Waterfall). Це саме можна сказати і до сектору мобільного розробки.
У замовника практично завжди є бюджет або очікування за вартістю, а також кінцеве завдання - додаток з певною функціональністю. Однак в продуктовій мобільного розробці застосування Agile більш виправдано.
Ми займаємося аутсорс-розробкою мобільних додатків, хоча використовуємо у себе Agile-інструмент - Pivotal Tracker (далі в тексті - PT). Саме про досвід його використання я хочу розповісти вам в цій статті.
Що нам було потрібно?
Коли над розробкою трудиться команда - менеджер проекту, кілька розробників і тестер - то в однієї сутності (сутність це завдання, таск, юзер-сторі або інше) може бути кілька станів, відповідальна особа і виконавець. Тому багато класичні таск-менеджери не підходять для обліку завдань розробки.
В кінцевому рахунку ми прийшли до того, що у сутності повинні бути наступні значення:
Що можна спробувати?
На ринку представлено багато інструментів для командної роботи (як для офісної команди, так і віддалених співробітників). Ми розглянемо тільки інструменти для взаємодії менеджера, розробника і тестувальника. Спілкування менеджера з замовником, менеджера з дизайнером і інші зв'язки не вимагають спеціально заточених інструментів, але і тут є цікаві практики - про це в іншій статті.
Відразу скажу, що місця папері в нашому workflow немає, всі інструменти тільки на комп'ютері. В основному зараз більше сервісів надається за моделлю SaaS, але є і рішення, які можна встановити у себе на сервері.
Напевно, це найвідоміша система трекінгу завдань, обговорень, файлів і подібного. Тому і проста, надійна і зручна. Дуже добре підходить для менеджерських завдань - прості чекліст, обговорення, спільне редагування текстів. Але зовсім не придатне для завдань розробки.
Завдання може бути в певному списку, у неї може бути виконавець, може бути термін. Я знаю людей, які для того, щоб віднести таск до певної версії продукту (Версія 1.0) писали в назві таска необхідну версію ( "Голосування за рейтинг [3.4]), а списки використовували для визначення статусів завдання (" Заплановано "," В процесі "," Завершено ").
Можливо для простих проектів - один менеджер і один розробник - Basecamp може підійти, але система руйнується, коли в проекті 2-3 розробника, тестер і менеджер проекту.
Відома платформа, яку люблять багато розробників. Встановлюється на сервері, легко Кастомізіруйте, має в наявність багато модулів. Для задач менеджер-розробник-тестер здається громіздкою. Інтерфейс аскетичний, а при наявності "Apple головного мозку" використання такого інструменту буде засмучувати =)
Монстр від компанії, яка з'їла всіх тварин в інструментах розробки ПО. Кастомізіруйте, масштабується - іноді заплутано і дорого, але багатьом дуже подобається.
GitHub Issues
Знаю, що в деяких колах популярний TFS, але вибачте - я навіть боюся дивитися туди)
Хлопці з Тематичні Медіа радили глянути на Asana, але теж якось не прижилося.
Чому Pivotal Tracker?
ціноутворення
PT не безкоштовний продукт, він стоїть цілком осудних грошей і працює по моделі SaaS.
За $ 100 в місяць ви отримали можливість созданіяе необмеженої кількості проектів і 25 учасників в них.
PT може інтегруватися з Google Apps, тоді запрошення співробітників в проекти стає простіше, а до ТАСК можна відразу прикріплювати документи з Google Drive (наприклад з описаної логікою).
У PT багато цікавих і прихованих можливостей, практично все описано в довгому Хелп - www.pivotaltracker.com/help.
Загальні правила
Ми не використовуємо поняття user-story як воно є насправді. У нас це просто таск / завдання.
В PT є 4 типи ТАСК - feature, bug, chore і release. Ми використовуємо ці типи так:
Feature - основих завдання щодо зміни або поліпшення функціональності
Bug - номер бага в Crashlytics, або короткий опис бага
Release - найменування версії билда (альфа, бета і rc)
Chore - завдання для менеджера безпосередньо пов'язані з розробкою або релізом
Фіолетовий лейбл це епік - ми використовуємо як його номер версії, в яку пойдте дана функціональність.
Зелений лейбл це тег - ми використовуємо його для вказівку розділів, до яких може бути застосована дана фіча (наприклад, blog view).
У кожному ТАСК можна вести обговорення зі згадуванням інших членів команди (їм прилетить нотіфай), можна додавати будь-які файли (найчастіше це скріншоти, наприклад до UI-багу), можна вести сабтаскі (зручно при pixel-perfect доробках).
Все епіки (epics) спочатку зберігаються в окремій вкладці. Ви завжди можете відкрити епік з якоюсь старою версією програми та подивитися коли певна фіча була реалізована, а також легко планувати roadmap для майбутніх версій. Кожен епік має свій унікальний номер, як і таск - завжди можна дати на нього пряме посилання.
Інтерфейс в PT є панелями: основні - backlog, icebox, current. Ми використовуємо тільки панель icebox (для зберігання ідей і тих ТАСК, які не входять ні в одну версію поки) і backlog (стрічка затверджених ТАСК), а також панелі, які викликаються через епіки - вони відображають таски тільки до обраної версії. На перший погляд того, хто цим не користуватися, все здасться дуже дивним - але потім ти настільки звикаєш до цієї системи, що на іншу дивитися просто не зможеш ніколи.
безпосередньо workflow
Менеджер має на руках ТЗ і roadmap за версіями. Починається процес створення ТАСК. Кожен таск обов'язково супроводжується епіком (якщо це розробка з нуля, то версія зазвичай 1.0) і лейблом по розділу (ми використовуємо лейбл як екран, тобто екран команди це "team", екран матчу це "match"). Все таски потрапляють в Icebox.
Далі таски переміщаються в Backlog. З цього моменту вони затверджені і у кожного таска повинен бути встановлений виконавець. Якщо на проекті один розробник, то це не потрібно. Якщо розробників кілька, то розподіл ТАСК здійснює тімліда проекту.
У кожного таска є рівень складності - це якесь абстрактне значення в поинтах (воно застосовується для підрахунку velocity, але ми це не використовуємо). Втім, без установки цього значення завдання не стартував. Після того, як розробник приступає до задачі, він натискає Start. По завершенню таска розробник натискає Finish. Наступний можливий стейт таска це Delivered. Це відбувається коли розробник доставляє таск в збірку.
Ми робимо п'ятничні збірки, в них якраз і потрапляють вже завершені таски. Роблячи збірку, розробник зазначає ті таски, які потраплять в збірку і які можна приймати менеджеру проекту. Менеджер може прийняти таск, якщо вважає що завдання зроблена як треба і функціонує, а може зробити реджект, вказавши причину. Після реджекта таск має стейт Rejected (кнопка - Restart) і до нього можна приступити знову.
Таким чином можна в будь-який момент зрозуміти чим займається конкретний розробник, які завдання вже реалізовані і потраплять в збірку, які ще в icebox і т.п. Це дуже зручно і наочно, також порядок завдань можна легко міняти - наприклад, в рамках одного релізу, або перекинути на наступний реліз.
Після рев'ю п'ятничної збірки менеджер також може створити таски, пов'язані з багами. У релізах зі статусами beta і rc підключається тестувальник, який також може створювати таски по Багам. Він потім і відповідає за те, щоб прийняти їх або реджектнуть після виправлення розробником.
Коли таск доставлений і прийнятий, то він стає зеленим і завдання закрита.
Розробники люблять вказувати в Ком в GitHub ID таска, тоді при пуші таск автоматично фінішує.
Особливості
У великих проектах кількість ТАСК може доходити до тисячі. Можна виробити свої принципи створення ТАСК і використовувати їх.
У випадку з автоматичним білд-сервером стейт таска на Delivered треба міняти коли зміни закомічени в репозиторій, тому що збірка відбудеться автоматично. Ну тут у кожної команди свої особливості.
У Pivotal Tracker є відмінні iPhone / iPad додатки (поки правда без адаптації до iOS7), також є сторонні клієнти під Android. Є інтеграція з усіма зовнішніми сервісами - Github, Campfire, FlowDock, HipChat, Zendesk і т.п.
Ми не надаємо доступ в Pivotal замовнику, але в разі такої вимоги в трекері є можливість запросити "спостерігача" з правами "read only".
висновок
Наші друзі з AviaSales також використовує цей інструмент як в серверній розробці, так і в відділі мобільного розробки. Друзі з Bambk використовують Pivotal для серверної розробки. Ми всі дуже задоволені, що такий інструмент існує на ринку і надає дійсно ті можливості, які нам потрібні. Впровадити використання Pivotal Tracker може як невелика команда стартапу, так і серйозна команда великого продуктового проекту або аутсорс-розробки.