McGray;s Tower

Посетил второй АВС и хотел бы поделиться впечатлениями. Ну во первых опять то же место проведения, что на мой взгляд скорее минус. Кейтеринг поменялся в лучшее сторону, но это скорее всего из-за того что цена посещение выросла в несколько раз :). Опять много старых друзей и знакомых. Некоторых не видел по 4 года. Но все же о докладах:

1. Алексей Кривицкий + Наталья Тренина “Аджалистам кое о чем, между прочим и на всякий случай” -

Доклад по большому счету не о чем. В очередной раз скажу о том, что Scrum Guides надо либо полностью перейти на тренинги или на конференционный бизнес. С  докладами не складывается.

2. Николай Алименков “Путь Agile проекта до первой итерации “ -

Николай порадовал новой темой близкой более к pre-sales чем к engineering. Суть доклада в том, что до старта проекта на Agile необходимо провести очень много активностей, множество из которых есть часть тяжеловесных процессов, но их тоже можно сделать Agile-way.

3. Андрей Бибичев “Think different” -

Очень общий не несмотря на это достаточно яркий доклад обо всех трудностях что встречаются на пути Software Development в наши дни. Высказана интересная идея по поводу Team Blog. Стоит проработать. Докладчика слушай первый раз, подача материала понравилась, но это скорее формат беседы, чем доклада.

4.  Николай Алименков + Алексей Солнцев “Применение практики “Code Review” для улучшения качества продукта” -

Ребята сделали доклад, как сборную всей имеющейся теоретической и практической информации по этой инженереной практике. Не так много нового но достаточно упорядочило мысли в голове.

5. Александр Орлов “Практические инструменты работы с мотивацией сотрудников” -

Александр представляет Питер, работал на Sun и IBM, руководил группами как разработки так и тестирования. Не так много нового но все сдобрено примерами из жизни и слушалось хорошо. Докладчика также слышал первый раз, манера подачи информации более-менее понравилась.

6. Асхат Уразбаев “Применение Lean в Offshore разработке” -

Первая часть доклада не порадовала, так как предназначалась тем, кто ничего не знает о Lean. Так как я уделял внимание этому вопросу ранее то было не очень интересно. Хотя манера подачи материала Усхатов в очередной раз порадовала. Вторая же часть навела на ряд очень интересных мыслей. Она содержала размышления о применении Lean у нас в оффшоре. Стоит подумать на досуге, особенно мне как тому что работает в Kanban команде и не понаслышке знает что такое Kaiden :).

PS. Коллеги и знакомые присутствовавшине на конференции рекомендовали также:

Тимофей Евграшин “Подводные камни управления agile проектом – как ответить на вопросы «когда?» и «сколько стоит?»”

Никита Филиппов “Формируем и Приоритезируем бэклог используя StoryMapping”

Артем Сердюк “Agile - нечто большее, чем инструмент? Быль-сказка.”

PPS. Как только слайды и видео появятся на сайте конференции, обязательно добавлю.

Удалось посетить мероприятие, несмотря на дефицит бюджета компании и мой личный. Начнем с самого главного. Если вы задумаете ехать в Питер на поезде  - откажитесь от этой идеи. Как показала практика - это потеря времени и денег. Ну а теперь про конференцию:

1. Гослинг не приехал :(, хотя персонально я ехал в том числе и чтоб посмотреть на дедушку). И теперь мы знаем почему.

2. Было такое чувство что на конфе собралась вся студота Питера. Так что было очень плотно. На некоторые доклады первого дня даже не удалось протиснуться. Второй день был лучше - по всей видимости част студентов отдыхала напившись пива после первого дня.

3. Как обычно много евангелизма. Много пассажей о том как хорош Oracle и как он теперь будет помогать развивать Джаву.

Ну а теперь про доклады. Понравился Мусин-Пушкин из Project Kenai и его доклады про Jave EE 6. Simon Ritter и его доклад про JDK7 и JavaFX. В общем доклады тут.

Если делать вывод по конференции в целом то можно сказать следующее:

1. Oracle уже наложил свою мохнатую лапу на Sun и теперь пытается его преобразить по своему образу и подобию.  Продукты Сана теперь будут интегрированы в систему “мы продаем все” от Oracle. И совсем не так уж ясно что нас ждет…

2. JDK7. Все будет хорошо

3. JavaEE 6. Теперь то, о чем “так давно говорили Большевики”  де-юре стало стандартом. Я не приветствую возгласов типа “да это давно было в Спринге и Хибернейте”.  Сан теперь просто поднял это на уровень выше сделав частью спецификации. Там конечно еще много ляпов, но это не последняя спека. Что еще хотелось бы сказать. Коллега недавно на мой подобный пассаж сказал “за время пока Сан придумывал эту спеку Спринг ушел еще дальше”. Согласен, но время покажет. Я не советую бросаться использовать GlassFish и NetBeans, но сам попробую также  как я сделал со Spring 3.

4. JavaFX. Мне как старому Флешеру приятно что теперь есть Флеш и на Яве. Теперь практически все что есть на Флеше есть и на JavaFX, что приятно. Кроме того скриптовый язык JavaFX можно использовать вместе с объектами Java. Кроме того переносимость  + удобные средства разработки. Не сказал бы что FX тепер заменит Флеш, но свою нишу он займет. Тем самым реализую принцип Oracle  - “мы продадим вам все”.

Пишу с огромный опозданием, кроме того многое уже успел забыть. Пока готовился написать был анонсирован второй ABC. Про первое мероприятие могу сказать только то, что не понравилось место проведения и кейтеринг.  Больше впечатлений оставили встречи со старыми друзьями, чем сами доклады. Но это, скорее, по причине избалованности. Писать отдельно по докладам не буду  - уже успел подзабыть. Но я первый раз слушал Асхата Уразбаева и как докладчик он произвел на меня впечатление. Доклад тоже был очень толковый. Еще был интересный доклад про Lean, но было слишком много общеизвестных вещей и я чуть не заснул посредине.

После почти полутора лет работы на Scrum сегодня было объявлено что Киевская команда переходит на Kanban. Это означает две вещи:

1-я : мы перестали быть проектной командой и наш удел maintenance.

2-я : теперь многое изменится в процессе…

Интересно что из этого получиться. Часть команды работала по Кандану уже полгода, так, что опыт есть. Сам участвовал в становлении процесса. Нам будет намного легче чем было им.

Как теперь жить без Daily Scrum ума не приложу

Посетил на выходных AgileEE. Ну что я могу сказать? Растем. Порадовал уровень докладчиков. Организация правда “на троечку”, но как говорится “первый блин …”. Ни в коем случае не хочеться приуменьшить вклад организаторов, просто невозможно сделать так, чтоб мы престали быть “страной зеленых помидоров”. А теперь к докладам. Небольшой рейтинг:

1-е место однознвчно за  - J.B. Rainsberger, “An Introduction to Agile Through the Theory of Constraints”
(лептоп докладчика приказал долго жить, так дядька рисовал слайды на планшете по ходе доклада - очень ярко)

2- местое: Jutta Eckstein, “Proximity Over Distance”
(все что надо знать нашим руководителям убила фраза - “You have to pay for face-to-face conversations either you have it or not”)

3-е место : Robin Dymond and Jürgen De Smet, “Cooking the Product Stew”
(так сказать рассказ о том как все в реальной жизни)

Также 3-е место : David Hussman “Agile Journeys: How Did We Get Here and Where are We Going?”
(лучше смотреть)

Просто понравились:

Yves Hanoulle
“Tips for creating a Self-Organizing team”

Szczepan Faber
“Java: tools & techniques for TDD”

Janet Gregory (2 hrs)
“Seven Key Success Factors for Agile Testing Success”

PS. Жду всез презентаций.

В последнее время часто задумываюсь, а хорошо ли, когда у программного продукта сложная архитектура? Хорошо ли это для тех кто на проекте работает. Много ли опыта можно получить, если работать с чем-то простым. Ведь делать хорошо простые вещи это тоже искусство.  Не придумывать решений сложнее чем необходимо для текущего продукта  - тоже нужное умение. Теперь для меня нет разницы между тем инженером, что работал над сложной системой поддержки принятия решений и тем, кто занимался автоматизацей службы заказов онлайн.

Старая пословица как никогда верна в наши дни, когда постоянно надо двигаться вперед, что-то делать и не стоять не месте. Но сделал для себя вывод что, когда выбираешь из списка задач что-то вроде: “Связаться с тем-то, обсудить то-то”, надо четко представлять, как пойдет беседа. Часто, получается, что желая закрыть тему, просто делаешь звонок, беседуешь с человеком и так ничего и не решаешь. То есть по сути теряешь время.

Иногда политика “Да, мой белый гаспадина…” приносит свои неожиданные плоды. А именно все всем довольны. То есть если ты хочешь работать как специалист наравне во спецами заказчика  - не надо добиваться признания этого официально. Пусть спецы заказчика говорят, что они делают очень много работы и, причем, самой сложной, а ты им просто помогаешь. На самом же деле все наоборот. Если забыть про гордость все может выйти совсем неплохо. Так тебя никто не достает, пытаясь показать что он тут главный, а ты себе работаешь. И при этом не выгодно говорить что ты плохо работаешть. Если тебя сместят, кто же будет делать всю работу, да еще и так чтоб можно было говорить обратное.

Не думаю что тработает всегда. Даже сказал бы что работает иногда. Очень редко. Но бывает.

О том что такое QA споры идут уже давно. Расшифровка аббревиатуры это Quality Assurance. Вопрос в том, что в нашей части света под этим очень часто понимают тестировщиков. А это не совсем так. Посмотрел в Википедии и вот что нашел:

Sub-disciplines

While Grace Hopper was working on the Harvard Mark II Computer at Harvard University, her associates discovered this moth stuck in a relay and thereby impeding operation, whereupon she remarked that they were “debugging” the system. Thus starting the popularity of the term software bug.

Software engineering can be divided into ten subdisciplines. They are:[1]
Software requirements: The elicitation, analysis, specification, and validation of requirements for software.
Software design: The design of software is usually done with Computer-Aided Software Engineering (CASE) tools and use standards for the format, such as the Unified Modeling Language (UML).
Software development: The construction of software through the use of programming languages.
Software testing
Software maintenance: Software systems often have problems and need enhancements for a long time after they are first completed. This subfield deals with those problems.
Software configuration management: Since software systems are very complex, their configuration (such as versioning and source control) have to be managed in a standardized and structured method.
Software engineering management: The management of software systems borrows heavily from project management, but there are nuances encountered in software not seen in other management disciplines.
Software development process: The process of building software is hotly debated among practitioners with the main paradigms being agile or waterfall.
Software engineering tools, see Computer Aided Software Engineering
Software quality
Software localisation, a branch of the language industry.

Отсюда:

http://en.wikipedia.org/wiki/Software_engineering#Sub-disciplines

И вот тут мне стало яснее что есть две дисциплины Тестирование и Контроль качества и состав у них немного разный. Для разнообразия можно посчитать статьи. Но мне понравилось вот, что:

Software Quality Assurance (SQA)

Though controversial[12], software testing may be viewed as an important part of the software quality assurance (SQA) process.[citation needed] In SQA, software process specialists and auditors take a broader view on software and its development. They examine and change the software engineering process itself to reduce the amount of faults that end up in the delivered software: the so-called defect rate.

What constitutes an “acceptable defect rate” depends on the nature of the software. For example, an arcade video game designed to simulate flying an airplane would presumably have a much higher tolerance for defects than mission critical software such as that used to control the functions of an airliner that really is flying!

Although there are close links with SQA, testing departments often exist independently, and there may be no SQA function in some companies.

Software Testing is a task intended to detect defects in software by contrasting a computer program’s expected results with its actual results for a given set of inputs. By contrast, QA (Quality Assurance) is the implementation of policies and procedures intended to prevent defects from occurring in the first place.

Взято отсюда:

http://en.wikipedia.org/wiki/Software_testing#Software_Quality_Assurance_.28SQA.29

Попробую подвести итоги уходящего года.

“+”

1. “Вытянули”  проект на пару с моим руководителем. Теперь он стал интересным для нас обоих и для людей, которые теперь с нами работают.

2. Наняли (сильно сказано, но другого слова подобрать не могу) классную команду. (Теперь уверен что это команда!).

3.  Теперь ТЛ (не уверен что это + конечно, но посмотрим).

4. В конторе стартовал Тех Толкс (надеюсь что я не слишком оптимистичен в этом плане).

5. “Отрубил”  один из старых “хвостов”.

6. Развернул ВордПресс на сайте  - где не было ничего порядка 2-х лет.

0. Чуть не забыл  - наверное самое интересно это встреча с моим текущим руководителем, многому смог от него научиться. (Риспект Андрюха!).

“-”

1. Контору уже “трясет”.

2. Не удалось придумать “свой”  проект.

3. Не выучил ни одного нового языка или технологии (ознакомление не считается).

4. Блог “замер”  - ни постов ни нового дизайна (хотя бы хедер поменял).

5. Доделал работу по “хвосту” , но так и не смог получить за это деньги (наверное так и не научился себя продавать как следует)

Планы на следующий год:

1. Придумать что-нибудь “свое”  и попробовать стартовать проект.

2.  Выучить новый язык и пару-тройку технологий.

3. Активнее работать с блогом.

4. Продолжить с ТехТолкс.

5. Не бросать проект и команду.