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

Важливо!
  • У статті присутня певна частка іронії.
  • Стаття ні в якому разі не порушує чиї-небудь інтереси.
  • У статті не протиставляється SCRUM водоспаду і не змішується «м'яке з теплим».
  • У кожного своя думка на процес розробки проектів, свій досвід або його відсутність, свій щасливий клієнт або свій провалений проект, виконаний за методологією, за допомогою проектних методик, керуючись принципами або інтуїцією.
  • Будьте добрішими!


image

Читати далі →

Скрамуниздили

-Я хочу влаштувати паніку, зрозуміло?
-Ти там бійню влаштуєш, а не паніку.

«Великий куш»

Протягом вже досить тривалого часу мені попадаються на очі пости, статті і навіть цілі книги, завдання яких — донести до читача поради про те, як правильно робити Скрам. Всі вони, загалом-то, однотипні і побудовані на припущенні, що більшість людей неправильно розуміють пропоновані практики, їх призначення і важливість. У цих джерелах активно доводиться, що Скрам все-таки працює, йдеться про прийняття цінностей, про перестроювання мислення на рівні компанії, про тонкощі організації мітингів та інших нюансах, яких за підсумками кожного разу набирається вагон і маленький візок. Судячи з усього, проблема дійсно існує, адже навіть Кен Швабер та Джефф Сазерленд описують Скрам як "легкий, простий в розумінні і складний в оволодінні" [1]. Але справа тільки в практиках? Може бути, люди не розуміють саму суть Скрама? Коли щось починає приносити серйозні гроші, то не секрет, що саме прибуток стає провідною зіркою цього корабля. Може бути всі ці тренінги, сертифікації і спішно переучивающиеся в скрам-майстрів менеджери проектів затьмарили собою початковий посил? Цілком ймовірно. Але чи це так? Даний опус — це спроба поглянути на проблему під дещо іншим кутом, з точки зору технічної, ніж який-небудь ще.

Читати далі →

Be Agile. Як піти від Waterfall

image

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

Якщо ви все ж зважилися спробувати нове. У цій статті я поетапно розповім як плавно перейти від Waterfall до Agile без втрат, ризиків і порушення основних налаженых процесів роботи.

Читати далі →

Кейс OZON.ru: Як зробити тарифікацію доставки прозорою і керованої

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

Ціна за доставку товару для покупця інтернет-магазину рідко збігається з ціною, яку транспортна компанія візьме з самого магазину. Захотіли ви привезти книги з допомогою DHL в Новосибірськ. OZON.ru виставить вам конкурентну ціну за доставку — 500 руб. При цьому DHL за цю доставку виставить OZON.ru рахунок на 1000 руб. Це здається дивним, але така реальність, яку диктує ринок.

Читати далі →

Про наш фінансовий відділ і власну CRM

Це перша стаття з серії про те, як ми впровадили безперервну інтеграцію в процес розробки CRM і полегшили життя фінансовому відділу.
Перш ніж описати технічні подробиці, розповім про передумови до розробки системи і про те, як фінансовий відділ працював раніше.
image
Раніше для автоматизації технічних процесів у фінансовому відділі ми використовували таку структуру.
Читати далі →

Комунікації в програмуванні — уві сні і наяву

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



Читати далі →

Моделювання спринтів Scrum. Вирішуємо проблеми взаємодії з клієнтом і всередині команди

«Мобільний додаток повинно бути «живим», користувач повинен бачити, що проект розвивається»
image
Ми в Redmadrobot працюємо по гнучких методологій Agile і Scrum. Як відомо, вони передбачають значну свободу в тому, як організовуються спринти за проектами, — кожна компанія підбирає зручну для себе модель. Кейсів — інформації про те, як організуються команди під час виконання спиринтов — у зовнішніх джерелах вкрай мало. Розкриваємо свою «кухню».

Читати далі →

70 епічних доповідей, божевільна agile атмосфера і 1000+ соратників чекають тебе на AgileDays'15!

Головна щорічна подія Agile галузі — AgileDays'15 пройде з 19 по 20 березня 2015 року в Центрі Міжнародної Торгівлі на Краснопресненській набережній, 12. У цьому році захід буде ще масштабнішим.

Традиційно програма AgileDays'15 включає в себе Keynotes від зарубіжних Agile-гуру, безліч тематичних доповідей, воркшопів та щорічно збирає в дні заходу більш ніж 1000 чоловік.

В 5 паралельних потоках будуть обговорюватися методології, що застосовуються для гнучкого управління процесами — Scrum, Kanban, Lean і т. д., продуктова розробка, інженерні практики і DevOps і багато іншого.

За формування програми відповідає Програмний комітет, також можна подати заявку на виступ з доповіддю.
Читати далі →

Gov.uk service manual: гнучка методологія розробки

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

Ми почали з блоку, присвяченого гнучких методологій проектування, розповіли про його важливої частини — створення так званого user-centered design, а зараз переходимо до гнучких методологій розробки.


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

Це означає лише, що ваша команда, користувачі та стейкхолдери почнуть працювати по-новому.

Розумійте ваших користувачів

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

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