Agile BaseCamp, Роздуми

2011-02-07T14:13:00.001-08:00

Lviv, February 5, 2011

Цей текст – це радше роздуми про конференцію БейсКемп аніж її звіт, бо не претендують на повноту чи то цілісність, адже я багато чого цікавого пропустив. Тим не менше.

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

Львів, кажуть, вразив багатьох учасників з інших міст. Невдало мабуть було вибрано лише час для вилазки для Львова – болотяну зиму. Звісно травень-червень завше краще у всіх містах, але у Львові суттєво розквітають юні панянки, і прокидається бруківкова частина міста – даунтаун, з безліччю кафе, а точніше кав’ярень. Але все ж дехто зумів побачити щось файне у таку нефайну погоду.

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

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

Захід обіцяв бути дуже міжнародним, але не було Роба Даймонда, якого я чекав. Зате були поляки, білоруси, росіяни ну і звісно українці, з поміж яких багацько було галичан. Взагалі львівська айті спільнота здається тільки-но прокинулася з цією конференцією, адже до Києва чи Харкова й десятої частини не приїздило. Хоча це не дивно.

Людей було багато, поза 300. Безліч знайомих і незнайомих, і напівзнайомих (ті, шо знають мене, але не вайс верса, і вайс верса). Один з таких напівзнайомих казав мені «привіт, я з Серва, ми з тобою про еджайл розмовляли по телефону». Я відповів – «привіт, давай якось точніше, бо я багато з ким з Серва про еджайл по телефону говорив». Він сказав «ну про скрам». Короче, - познайомилися.

Особливо виділити потрібно хол, а саме те, що там відбувалося – нарід тішився Кінектами, що їх привіз Серв. Я не вперше бачив кінект, бо вже пробували хакати його трохи, але вперше бачив танцюючих хостесів і ейчарок танцюючими з кінект – це було … «ніжно»). Взагалі такі девайси дуже корисні, і, сподіваюся, наступного разу з їх допомогою доповідачі будуть перемикати слайди, та робити інші сексі речі під час презентацій (МС дозволили хакати кінект так шо процес вже пішов).

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

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

Особливо також відзначу інтернет – коннекшин був су перовий і постійно.

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

Перед 9 ранку почали прибувати аттендіс, реєструватися, отримувати у подарунок всілякі корисні девайси типу ручка, карти, папірці.

Почалася конференція, вранці, о 9.50. Розпочали як завше Льоша і Наталя, розказали троха про історію, як то все почалося. Як то все закінчиться не пояснювали, і це добре.

Потім був перший спіч.

Спіч1, перша сцена. The craft of making software, by Pawel Lipinski. 10:00 – 10:45

The craft of making software

View more presentations from Pragmatists.

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

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

Перерва 15 хв

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

Спіч2, перша сцена. Agile Contracts, by Piotr Zolnierek. 11:00 – 11:45

Agile Contracts with Fixed Budgets

View more presentations from Piotr Zolnierek.

Я цей спіч пропустив, адже пішов на другу сцену до Романа слухати про паттерни. З того, що чув про презентацію від колег, вона була типу кейс стаді чи то саксес сторі. Я очікував більше типів контрактів, “money for nothing, changes for free”, з шарад ризиками, про те як поводитися на прі-сейлі, як і шо говорити, можливо шось про MoSCoW прінсіпл і фіксування еMок і еSок. Ну, але кейс стаді це теж цікаво, не завжди ж тулити сиру теорію. У слайдах знайшов накидання ризиків, - ну це ясно. Як казав один з підписантів маніфесту, «лет йор кастомерс пей фор анноунс» - у цьому є сенс. Далі можня релятивно шось там міряти, авераджати, проектувати, релізати і тд. Одним словом, шкода, що пропустив.

Спіч2, друга сцена. Scrum Master Anti-Patterns, by Roman Makushnyak. 11:00 – 11:45

Scrum Master Anti-Patterns

View more presentations from Roma Mack.

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

Роман говорив вільно і чітко. Описав декілька класичних проблемних ситуацій, що часто виникають у аутсорсингових фірмах, що починають транзишин до еджайл, а також вже давно перейшовших. Адже тайтли у нас ще ніхто не відміняв. Не може ж українська душа так швидко переметнутися з техліда на просто Тім Мембера?! ))

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

Спіч3, перша сцена, Успішне впровадження Agile. Моделі та поради, Олексій Кривицький, 12:00-13:00

Successful Agile Adoption. Models and Advices

View more presentations from krivitsky.

Це моя секонд зе бест, що і вказав у фідбек формі. Сподобалися одночасно і подача і контент. Контент близький мені, адже зараз займаюся масовим вровадженням. Було цікаво почути про різні паттерни і стратегії розвитку, переконування, скейлення і тд. Подача звісно заслуговує на увагу завдяки історії про пінгвінів. І кожній фразі цієї казки було настільки багато фану і водночас правди, що публіка не вщухала. Спіч був повним, збалансованим, і, якщо одним галицьким словом – файним. Якщо порівнювати з Павелом, то у Льоші було більше часу, на 15 хв. А це я вам скажу – доволі велика перевага. Відповідно було більше часу жартувати і встигнути цілісно донести контент нічого не вирізаючи.

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

Дякую Льоші за хорошу презентацію.

Спіч3, друга сцена, Dependency Injection…, by Дмитро Міндра. 12:00-13:00

Dependency Injection або Don’t call me, I’ll call you

View more presentations from Dmytro Mindra.

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

Обід

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

Далі буде…

Assumption management

2009-12-17T08:24:00.000-08:00

I believe everyone would agree there is a long road from requirement to actual code. This road is filled by discussions, strategies, assumptions etc. Often, requirements are not clear. Often, technical approach/design is not clear. Not all developers are senior guys. And now, imagine – you are doing product using Agile Scrum in distributed environment. You want to deliver fast so using 2 weeks sprints. Product Owner doesn’t sit with a team as well as architect group is located on other end. And there is 8 hours of time difference.
Impossible, right? But didn’t you meet such cases?
What we usually do if developer does not fully understand the requirement? Fire requirement ticket to product manager (owner), or set status of issue to ‘need info’ or write an email and wait until next business day. Or further. And this is even not only about distributed teams, what if Product Owner has vacation/business trip etc even if sit with a team?
Okay, you will say ‘Scrum has answer to this’ – let developer authority to assume and do. In best case, he will write and email or comment on issue/task/bug. Often, we will lose this comment at least for few days. If assumption was bad – you will get either bad approach or unexpected behavior. And you will catch that on sprint review. Not too bad, but not great.
So, how to manage those assumptions in comments, email threads or developer minds accurately and fast?
What if immediately put a sub-issue to issue developer currently working on? Or create new issue and somehow link them? And have dashboards organized well so Product Owner, or Architect or whoever responsible for assumption confirmation is, will see it immediately ones get to office. Or even from home. And he will resolve it as developers do with bugs. He will also see for example the status of assumption (in use) – so that will mean it is critical for him to resolve/confirm ASAP. That would be enough agile, right?
And that would be also good and organized history of requirement taking into account wordless executable user stories.
Other sample. Let’s say we have one team sitting together and using board with sticky notes for their tasks. We could just put red sticky note on one for task with assumption written. Someone do that for blockers. Product Owner will confirm once get into office from business trip, and you wouldn’t forgot.
We will assure that the developer did what PO expected. We will assure that he did that how Architect expected. And this process is very simple and fast. So idea is to note what in mind somehow and somewhere, but do it accurately, within a process even if simple and have any handling mechanism.

Nature of agility

Agile BaseCamp, Роздуми

Спіч1, перша сцена. The craft of making software, by Pawel Lipinski. 10:00 – 10:45

Assumption management