Три тижні тому мну мав змогу побувати на Agileee: третій східноєвропейській конференції по agile методологіям розробки. Два дні занурення в позаробочу ІТ-атмосферу спілкування та обміну досвідом (бачив кілька колишніх співробітників – всім привіт ^_^). Дуже надихаючі два дні. Так, там часто говорилось про речі, які здавалося б очевидні і відомі, але описані іншими словами, або просто практичними прикладами вони набували іншого сенсу, що давало можливість поглянути на відому сутність з різних сторін.
Мінусів було не так багато. Найбільший – вартість заходу. 300 ойро я сам особисто навряд заплатив би навіть за таку чудову конференцію (тому дякую MD за надану можливість ^_^). Ще один момент з яким навряд можна щось зробити – це те, що деякі цікаві (і навпаки нудні) доповіді були паралельно і доводилося мучитись вибором між двома. В результаті я не потрапив на дуже цікаву судячи по слайдах “Programmers Anarchy” 🙂
Ну а тепер трохи про найбільш цікаві доповіді та ідеї…
“Effective Software Development in the 21st Century: The New Face Of Software Engineering” by Dr. Alistair Cockburn
Найцікавішою для мене частина була про “Flow management”, оскільки це були одні з граблів на які я вже встиг наступити і почерпнув деякі (здавалося б цілком очевидні) ідеї відносно правильної організації роботи. Звісно, сам принцип розбиття слона на маленькі шматочки, які можна проковтнути замість того аби надкушувати його з різних сторін – відомий, але по-людськи орагнізувати це мені не вдалося і зрештою все скотилося до малюнку справа. І саме під час доповіді у мене з’явилися ідеї як це можна було б реалізувати значно краще, і чому у нас вийшла така лажа і затримки з написанням вимог до софту. Якщо описати коротко, то ідея полягає в тому, щоб перетворити затори на постійні потоки балансуванням завантаження: в нашому випадку ми самі створили собі затор у вигляді системного аналітика в той час як просто правильно обираючи невеликі шматки для реалізації можна було організовувати “зелені коридори” для тих чи інших фіч, коли всі, хто задіяні у її створенні, не мали б постійно чогось чекати (насправді все одно це було б не так просто, але позбавило б значної кількості головного болю точно).
Інша цікава частина – про ефективні комунікації, яка спонукала якомога частіше використовувати засоби до візуалізації, які значно покращують сприйняття інформації. Наприклад, для географічно розподілених команд – замість документу/електронного листа одна з опцій була використовувати відеозаписи, а замість звичайного телефонного спілкування – відеодзвінок, на якому було б ще видно whiteboard.
Було трохи про загальновідомі речі типу того, що варто всі ризики зміщувати на початок проекту наповнюючи свій багаж знань про нього, аби далі значно точніше оцінювати залишки роботи. І знову ж таки хоча на нашому проекті намагалися йти цією стежкою, але не в усіх можливих аспектах.
Коротше кажучи, одна з найбільш заслужених доповідей серед “keynote” (ключових).
Keynote by Dr. Alistair Cockburn at AGILEEE 2011 from AGILEEE on Vimeo.
Effective Software Development in the 21st Century
View more presentations from Agileee
“Challenging requirements” by Gojko Adzic
Непогана лекція про те, що ніколи не варто сприймати вимоги до ПЗ в тому вигляді, в якому вони приходять від замовника, а завжди докопуватись до самої сутності їх потреб – навіщо воно їм треба. Просто багато цікавих прикладів, причому не лише у сфері розробки ПЗ: найцікавішим був приклад про те, що F-15 Eagle, один з найуспішніших в історії винищувів, свого часу виграв тендер незважаючи на той факт, що він не виконав основну технічну вимогу – швидкість більшу за 2.6 махи. Інженери виявили основну причину цієї вимоги – радянські ракети літали зі швидкістю 2.6, тому більша потрібна була, аби мати можливість втекти від них – і замість того щоб робити як було написано у документі – зробили літак неймовірно маневреним. В результаті – виграний тендер і (судячи з Вікіпедії) жодного програшу в понад 100 повітряних дуелей. Отаке.
Challenging Requirements/Oredev
View more presentations from gojkoadzic
“Overcoming Self-organization Blocks” by Andrea Provaglio
Вельми цікава лекція про те як змінити свої погляди на командну роботу, створювати правильні “потоки креативної енергії” і уникнути типових помилок, які заважають команді самоорганізовуватись, а останнє – це ключ до її успішності.
Одна фраза, яка сподобалася багатьом присутнім: “In school if you copy you steal (you’re a bad guy). Is software if you copy you collaborate.” Говорилося це в контексті того, що поточна система освіти робить фокус на персональній, а не колективної роботі, обмежуючи останню і відкладаючи отримання одного з найважливіших практичних навичок у реальному житті на потім.
Andrea Provaglio “Overcoming Self-organization Blocks” from Agile Eastern Europe on Vimeo.
Overcoming Self-organization Blocks
View more presentations from Andrea Provaglio
“Motivation 3.0 and Agile” by Danny (Danko) Kovatch
Мабуть найбільш цікава доповідь з усіх. Тут було багато про що: і про творчу роботу та самомотивацію людей (основна ідея – не пробувати мотивувати, а просто не заважати закладеним в людях творчим імпульсам), про Atlassian FedEx Days (про який ми згадували сьогодні, щоправда я помилився – робота все-таки має відноситись до продукту, але не бути офіційним завданням). Шкода, що відику (ще) немає, але є сама презентація:
View more presentations from Agileee
“Inside Iteration Zero: simple steps to make great products” by Nikita Filippov and Askhat Urazbaev
Ідея з story-mapping’ом та backbone (хребтом) проекту – це круто. Сама ідея з backbone витала в повітрі з самого початку, але я не знав навіть, що у неї є назва і більше того: є певні інструменти як її реалізувати.
Simple steps to makes great products
View more presentations from Nikita Filippov
Сама доповідь була подана так собі (ІМХО), та після неї я поліз в Інет шукати інфу про story-mapping і знайшов іншу, більш детальну і практичну презентацію від Паттона:
View more presentations from Naresh Jain
“Programmer Anarchy” by Antonio Terreno
На цій доповіді я не був, але проглянув презентацію – вельми цікаво. Дуже багато чого перекликається з модним нині Kanban і в певній мірі це мрія кожного манагера – вибудувати команду, яка буде настільки самоорганізованою, що він стає непотрібен 🙂 Деякі речі звідси насправді з перемінним успіхом намагається прищепити нам наш department manager, але не всі ще розуміють чому це кльово і навіщо це потрібно. Шкода, що багато чого реалізувати в такому ключі не вийде із-за специфіки наших продуктів.
View more presentations from Antonio Terreno