Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2019

Visual Studio 2010 (and .Net Framework 4.0) Beta 1

My congratulations to the .Net community and all .Net professionals: .Net Framework 4.0 Beta 1 and Visual Studio 2010 Beta 1 are available for download!   There are a couple of very useful links to read more about new look and new features of these incredible products form Jason Zanders’s (who is actually the General Manager for the Visual Studio team in Microsoft) blog: VS2010: On Triangles and Performance Announcing VS2010 / .NET Framework 4.0 Beta 1! General Download of VS2010 / .NET Framework 4.0 Beta 1   .Net Framework and Visual Studio are the key products for the Microsoft Development Division, so you can hear much buzz around this beta on the pages of other Microsoft managers' blogs. E.g. VS 2010 Extensibility featured on Scott Hansleman's blog: Demo Dashboard and IDE Extensions - Whirlwind Tour around .NET 4 (and Visual Studio 2010) Beta 1 And Visual Studio 2010 SDK also already comes in Beta 1, you can find download link at the VSX Team Blog: Announcing the Visual Studio 2010 SDK Beta 1 Extensibility features are my favorite because I am a part of Extensibility team (Extension Manager and VS SDK are those VS 2010 features which I worked on).

Categories: Development | Microsoft
Posted by Vitalii Tsybulnyk on Friday, May 22, 2009 4:25 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Первый взгляд на Visual Studio 2010

Прежде всего разрешите представить: Jason Zander, General Manager продукта Visual Studio в Microsoft. Его блог не только хороший источник полезной информации о новых продуктах Microsoft "из первых рук", но и своеобразный индикатор политики неразглашения для других членов команды Visual Studio: если информация прозвучала со страниц этого блога, то она более не является коммерческой тайной и может озвучиваться кем угодно. Сегодня я хочу обсудить пост, посвящённый новому интерфейсу Visual Studio 2010. Более детально об улучшениях в UI можно узнать непосредственно из блога Jason'а, я же пройдусь тезисно по основным (на мой взгляд) пунктам:  1. Новый UI Visual Studio сделан на WPF, т.е. выглядит более "кульно" (но пока что работает заметно медленнее). 2. Окна с документами могут покидать границы оболочки VS и существовать как независимые окна, что должно безумно порадовать любителей работы с несколькими мониторами. 3. Строки, в которые были внесены изменения, оттеняются цветными полосками слева. 4. Multi-targeting включает все Framework'и от 2.0 до 4.0 включительно (что есть по сути первым полноценным multi-targeting'ом, т.к. у фреймворка 4.0, в отличие от 3.x, новый рантайм). 5. Extension Manager и Visual Studio Gallery - новый огромный шаг в сторону расширяемости и дополняемости VS. Поскольку это именно та функциональность, к которой приложил руку и ваш покорный слуга, отмечу особо, что для расширений VS не только введено централизованное хранилище, легко доступное из самой VS, но добавлен наглядный мониторинг и менеджмент установленных расширений, а также и разработка всех типов расширений существенно упрощена благодаря новым шаблонам в VS SDK. Если вас заинтересовали нововведения Visual Studio 2010 - очень скоро всё это можно будет попробовать на бета-версии, выход которой запланирован на весну.  

Categories: Development | Microsoft
Posted by Vitalii Tsybulnyk on Tuesday, February 24, 2009 5:48 AM
Permalink | Comments (4) | Post RSSRSS comment feed

SCRUM в Microsoft.

Момент истины - барабанная дробь, и... Да, в Microsoft испльзуют SCRUM! Не уверен, что абсолютно для всех своих продуктов, но для большинства наверняка. Лично меня это обстоятельство весьма удивило, ведь я ещё помню времена появления и бурного продвижения "водопадно-спирального" MSF, когда достаточно уверенное владение MSF требовалось даже для весьма "попсового" сертификата MCSD. У меня ещё где-то валяются пару увесистых справочников по MSF, которые я планировал когда-нибудь заучить наизусть в качестве "идеального" процесса разработки, который испльзует "сам Microsoft!" Не судьба. Видимо ближайшее время этим справочникам место на свалке, как и любой идеологии, в которую уже не верят даже сами её создатели. Удалось пообщаться со старожилами Microsoft, которые ещё работали согдасно MSF, и работали надо признать весьма успешно. Однако после провала MSF в одном из крупных продуктов (как я понимаю, это был Windows Vista, выход которого был задержан на 2 года в том числе и по причине несовершенства процесса), Microsoft массово перешёл на SCRUM, где пребывает и по сей день. Тем не менее, искушённый читатель нверняка знает, что "провозгласить следование процессу SCRUM" и "следовать процессу SCRUM" - это, как говорят в Одессе, две большие разницы. Поэтому немного о том, как именно в Microsoft соблюдается SCRUM:  - работа над продуктом ведётся небольшими командами по 5-10 человек, в которых присутствуют представители 3-х ролей: Developer, QA, Program Manager.  - работа каждой команды над своей частью проекта разбита на небольшие промежутки времени, sprint'ы продолжительностью 20-30 дней, к концу каждого из которых выделенный "кусочек" функциональности доводится до необходимого уровня готовности, задаваемого в начале спринта.  - внутри каждой команды каждый день проводятся 15-тиминутные SCRUM митинги, задача которых - "держать руку на пульсе" спринта, а именно каждый участник спринта говорит о работе за последние 24 часа и на следующие 24 часа. Если возникают вопросы или есть почва для дискуссии, то назначается отдельный митинг, куда приглашаются только заинтересованные участники. Таким образом оперативно устраняются "блокировки" в работе и всегда можно проследить динамику протекания спринта, затраты времени на ежедневные митинги при этом минимальны.  - SCRUM соблюдается также и в том, что называется "атрибутами процесса", а именно в определённой форме документирования задач и их готовности, сбора метрик и т.п. Вы спросите: а как же тогда известные утверждения о том, что в Microsoft у всех всегда есть менеджер и любой сотрудник находится не дальше чем в 7-ми ступеньках от Стива Балмера? Это правда и в этом "изюминка" реализации SCRUM в Microsoft. Помимо SCRUM-команд, которые формируются динамически согласно требований продукта, и все участники которых выступают как равноправные individual contibutors, все сотрудники ещё входят в состав определённых "статических" команд, которые формируются по признаку специализации (может быть команда только developer'ов или только QA, никаких "смешений"). В этих "статических" командах роли уже распределяются в "классическом" иерархическом представлении: individual contibutor, senior individual contibutor, team manager (например developer - senior developer - development manager или QA - senior QA - QA manager). Состав этих команд меняется намного реже, т.к каждый участник такой "статической" комады может учавствовать в одной или нескольких (или ни одной) SCRUM-командах. Менеджер такой команды является непосредственным "начальником" для каждого члена команды, а у менеджеров команд есть в свою очередь свой "специализированный" (development или QA) менеджер продукта, а у тех - general manager продукта, что и представляет собой известную иерархию Microsoft.

Posted by Vitalii Tsybulnyk on Wednesday, January 21, 2009 11:13 AM
Permalink | Comments (8) | Post RSSRSS comment feed

Немного важных закономерностей

Пройдя несколько тренингов в Microsoft, захотелось поделиться очень занятным графическим материалом. Зависимости, отображённые на приведённых далее графиках, большинству из нас известны исходя из личного опыта или профильной литературы, однако лишний раз посмотреть на визуализацию этих зависимостей, я думаю, будет не вредно. Итак, Зависимость стоимости исправления дефекта от стадии жизненного цикла проекта, на которой этот дефект был допущен: Вцелом график интуитивно понятен и не требует особых комментариев, однако для меня стала приятным сюрпризом "особенность" на графике для деффектов, допущенных на стадии Architecture, в районе перехода от стадии Construction к System test. Предоставляю каждому осмыслить её самостоятельно, скажу лишь что ранее она мне в литературе не попадалась, хотя на опыте мы несомненно её ощущаем почти всегда.   Успешность (вклад) участника проекта на разных этапах разработки: Несомненно, наибольший интерес представляет разделение здесь "объективной" успешности (сплошная линия) и "субъективной" (пунктирная), т.е. видение своей успешности самим участником. Если "объективная" кривая очевидна и понятна всем, по "субъективную" лично я в литературе никогда раньше не встречал и знал о её существовании только интуитивно. Знание и понимание этих закономерностей ценно не только для менеджера, которому это может помочь в нужный момент поддержать мотивацию членов команды и командный дух, но и для каждого участника, т.к. даёт возможность правильно рассчитать самонагрузку и избежать психологических перегрузок. Думаю, сознательное и умелое использование этих знаний могло бы уберечь немало "сгоревших на работе" или "опустивших руки" девелоперов от ухода из проекта и даже сохранить целые команды, однако только в Microsoft я впервые столкнулся как минимум с пониманием и демострацией этих закономерностей.

Posted by Vitalii Tsybulnyk on Monday, December 8, 2008 7:45 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Необходимо ли нам образование?

Последние посты Паши Подлипенского просто таки цепляют своей актуальностью. Вот и ещё к одному не смог остаться равнодушным. Немного обобщая, сформулирую суть поста. Поднимается наболевший вопрос "какова роль высшего образования в карьере современного ИТ-шника на пост-советском пространстве?" и в качестве ответа предлагается следующий: "При нынешней системе образования польза от ВУЗа стемится к нулю (кроме общения с некоторыми преподавателями-практиками), что признают также и работодатели": от некоторых организаций начали поступать прямые предложения о подготовке именно таких «полуфабрикатов» в течение первых двух лет учебы. В качестве варианта решения проблемы предлагается превратить университеты в почти аутсорсовые компании. И вместо элементарных лабораторных работ на 1-2 курсах выполнять небольшие проекты. В основном саппорт старых продуктов, баг-фиксы. Этот опыт поможет молодым специалистам ознакомиться с архитектурой сложных систем на практике. На 3-5 курсах, уже можно браться за исследовательские проекты и проекты, требующие реализации сложных алгоритмов. Что тут можно сказать?   Во-первых хочется немного "обыграть" утверждение о бесполезности высшего образования. Как мы это можем утверджать? Ответ довольно очевиден - 95% всего, что изучается в ВУЗе, среднестатистическим ИТ-шником потом нигде и никогда не используется. Согласимся с этим. Только ли у ИТ-шников дела так плохи? Думаю что нет. Думаю 95% того что учат будущие врачи тоже им без пользы: ботанику, химию и т.п. Думаю то же самое подтвердят представители большинства профессий. Что же делать? Институт высшего образования исчерпал себя? Копаем дальше. Кто последний раз на работе использовал интегрирование? дифференцирование? законы гидродинамики? формулы органических соединений? стихи Шекспира? А это уже программа старших классов... Как насчёт систем алгебраических уравнений? теоремы Пифагора? стихов Пушкина? пестиков и тычинок? валентности химических элементов? А это уже средние классы пошли... И наконец, кто когда последний раз умножал в столбик? разбивал слова на слоги? делал разбор предложения? нет? А это уже младшие классы! Можно так дойти до утробы матери и понять, что 95% всего, что мы делали когда учились, мы не используем!   Какой тут можно сделать вывод? Не нужно искать в учёбе точных аналогий тому, чем мы занимаемся сейчас. Их быть не может, да и не должно. Когда мы подтягиваемся на перекладине, то в 95% случаев мы не хотим просто больше подтягиваться, мы хотим быть сильнее, выносливее и здоровее, и это работает! Конечно, есть 5% "счастливчиков", которые с детства поднимали гири и потом пошли разгружать арбузы, но если даже грузить арбузы мы не хотим, это не значит что на гири нечего смотреть Возврашаясь к теме высшего образования, не стоит мерять его полезность количеством классов на С++, которые вы потом смогли использовать, или современностью языков программирования, или глубиной изучения сетевых протоколов. Это всё вы без труда освоите сами применительно к тем проектам, над которыми вы работаете. Почему без труда? Да потому что за эти 5 лет в ВУЗе вы научились главному - УЧИТЬСЯ. Вы получили, усвоили и использовали столько разнообразной информации, что стали УМНЕЕ, вы стали лучше УМЕТЬ ВОСПРИНИМАТЬ И ОБРАБАТЫВАТЬ НОВУЮ ИНФОРМАЦИЮ, а это ценнее и труднее всяких конкретных знаний. Конечно, соблазн потратить это время "с бОльшей" пользой велик - за это время можно стать Senior'ом в своей области, но поддаваться не стоит. Шанса получить тот кругозор и "прокачать" свой интеллект уже не будет. Через 7-10 лет разница в опыте сотрётся и вот здесь я делаю ставку на человека с высшим образованием. Я думаю он пойдёт дальше. Кроме того, через 10 лет может появиться совсем новая технология, в освоении которой у человека с высшим образованием огромнейшая фора. Да и новые технологии придумать может только человек, у которого больше запас разнородных знаний и аналогий, чем только опыт конкретной работы.   Но это всё красивая теория... А что суровая действительность? К сожалению, на пост-советском пространстве долговременные инвестиции (которой на мой взгляд является высшее образованиее) не в моде ввиду изменчивости всего происходящено. Все хотят заработать побыстрее и побольше, а иногда это жизненная необходимость, поэтому я не осуждаю тех, кто бросил ВУЗ и пошёл работать - это их выбор и им виднее насколько он верный. Я обращаюсь к тем, кто дошёл до конца и получил эту "корочку" - не жалейте! Может ваши выгоды пока не очевидны, это не значит что их нет. И уж совсем на последок - пару слов ИТ-шникам. Ни в одну ИТ-компанию мирового уровня (Microsoft, Google, IBM...) вас не наймут без высшего образования, а они знают что делают. Более того, на собеседованиях в такие компании только 50% (а то и менше) внимания уделяется вашим профессиональным навыкам, остальное - мышление, логика, математика, алгоритмы и решение проблем - то, что может дать только высшее образование. Не лишайте себя перспектив

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Wednesday, November 19, 2008 11:26 AM
Permalink | Comments (9) | Post RSSRSS comment feed

Почему производить ПО настолько сложно?

В индустрии программного обеспечения очень часто возникают различные вариации одного и того же вопроса:  - Почему производить ПО настолько сложно? Вопрос этот может звучать несколько по-другому:  - Почему нельзя точно спланировать разработку ПО?  - Почему нельзя найти и исправить все ошибки в программе?  - Почему разработчики так часто ошибаются?  - Почему больше половины проектов по производству ПО терпят провал?  - Почему с ростом сложности проекта затраты времени и ресурсов растут нелинейно? и т.п., но думаю корни у всех этих вопросов одни и те же, и состоят они в следующем. Человечество за всю свою историю научилось делать очень много сложных и очень сложных вещей:  - выращивать животных и растения, выводить их новые породы и сорта;  - строить себе дома гигантских размеров, способные выдержать даже серьёзные стихийные бедствия;  - лечить большинство болезней, успешно осуществлять хирургическое вмешательство в организм;  - создавать и успешно использовать сложнейшие механизмы и электронные успройства;  - химическим путём получать вещества и материалы с необходимыми нам свойствами;  - выходить далеко за пределы своей планеты и даже её орбиты, заглядывать в дальние уголки вселенной;  - наблюдать и использовать поведение и энергию мельчайших частиц материи и многое-многое другое. По сравнению с этими невероятными достижениями разработка ПО кажется детской забавой. Однако у всех этих достижений есть некоторые общие черты:  - всему этому человечество училось постепенно, шаг за шагом, иногда веками;  - массовое использование нового знания или умения как правило не начиналось до полной уверенности в том что метод работает и работает хорошо;    как следствие - то, что использовалось массово, как правило было надёжно;  - каждое такое достижение имело явно выраженную материальную составляющую:    механизм, прибор, материал и т.п. являются объектами материального мира с определёнными физико-химическими свойствами,    а значит все они подчиняющиеся определённым законам физического мира. Что же случилось с появлением компьютеров и программ для них? Человечество вошло в век ИНФОРМАЦИИ. Что это для нас изменило? Изменение стало весьма существенным, появилась возможность делать две абсолютно новые вещи: 1. Моделировать объекты реального мира, т.е. создавать сколь угодно много функциональных копий своего мира, что открыло новые невероятные возможности для его изучения и подчинения себе. 2. Не слепо следовать физическим, химическим и прочим законам своего мира, а создавать новые "виртуальные" объекты, аналогов которым нет в реальном мире, которые подчиняются собсвенным (нами же созданным) законам. Второе как раз и стало тем "новым измерением" которое получило человечество в своё распоряжение и которое вновь приближает нас к теме поста. Войдя в век инфрмации и придумав компьютер - универсальное средство создания, обработки и воспроизведения этой информации - человечество более не ограничивалось законами реального мира, мы создавали "миры" по мере нашей необходимости и совершенствовали эти миры под наши растущие потребности. В качестве примеров этих миров можно назвать:  - мир оффисных работников с документами, слайдами и самоподсчитывающими таблицами, размер, цвет, содержание и прочие параметры которых легко изменяются по первому желанию обитателя этого мира;  - мир игр с таким разнообразием подмиров и живущих в них существ, что порой диву даёшься фантазии создателей этих миров;  - мир музыки, которая не может быть воспроизведена ни на одном "реальном" музыкальном инструменте и т.п. Какое же место принадлежит во всём этом разработчику программ? Как ни пафосно это звучит, но ему принадлежит роль Творца миров и объектов в этих мирах. Забавно, но даже термин "объект" сохранён в науке программирования и имеет именно такой смысл, как мы только что интуитивно вывели. Думаю дальше все постепенно становится на свои места. С одной стороны мы имеем реальный мир с реальными объектами и законами, которые изучались человечеством тысячелетиями и изучаются до сих пор, которые покорить безумно сложно, но покорив однажды, мы овладеваем этим знанием и умением навсегда. С другой стороны - "мир миров", причудливые, изменчивые и непредсказуемые творения человеческого гения, который только входит во вкус, открывая в себе всё новые, казавшиеся ранее невероятными, возможности. Думаю не нужно приводить много примеров тех конкретных трудностей и препятствий, которые встречает творец-разработчик на своём пути: это и непротиворечивость законов нового мира (операционной системы, фрейворка), и безошибочность соблюдения этих законов применительно ко всем объектам мира (программ, окон, контролов, файлов), и гибкость мира, творцом объектов в котором может стать кто угодно, и трудности создания новых объектов с абсолютно новыми свойствами, которые до появления объекта и описать-то толком никто не может, в мирах, которые существуют только пару лет (вместо сотен миллиардов) и которые, во-первых, неидеальны сами по себе, а во-вторых, всё время продолжают развиваться и изменяться, приобретая новые невероятные свойства... Думаю, на этом можно остановиться, т.к. целью поста не является донести сложность и креативность нашей работы до людей неискушенных, думаю это дело мне не по зубам. Я лишь хотел объяснить нам самим, почему нам так трудно хорошо делать свою работу и почему мы почти никогда не справляемся со своей задачей на 100%. Мы ведь только учимся. В добрый путь, господа Творцы!

Categories: Development
Posted by Vitalii Tsybulnyk on Friday, October 17, 2008 7:14 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Дай своей конторе второй шанс

Давече наткнулся на занятную одноимённую статью на любимом мною developers.org.ua. Автор выступает от имени HR-менеджера, которому остро наболела проблема текучести кадров в украинском ИТ-бизнесе. Густо  напичканая логическими умозаключениями и примерами из реальной жизни, статья тем не менее сводится к тому, что программисты в большинстве своём народ замкнутый и нелюдимый, как правило не приходит к руководству со своими проблемами, а сразу ложит на стол заявление об уходе. Несмотря на лёгкий реверанс о том, что "менеджеры тоже у нас не очень", в статье явно видна предвзятость автора, что вобщем-то понятно. Намного больший интерес лично для меня было просмотреть комментарии ИТ сообщества к этой статье, по которым очевидно что автор поднял настоящую бурю. Как и следовало ожидать, мнения можно разделать на две основных группы: 1) автор молодец, программисты замучили своим нелогичным поведением и нежеланием помочь менеджерам, которые с ног сбились ублажать девелоперов; 2) автор - яркий пример безграмотного менеджера, а понимать и предвидеть настроение сотрудников - и есть одна из основных задач менеджера. Признаться, я не сразу определился "с  какой стороны баррикад" нахожусь я, однако "выслушав" несколько десятков мнений, понял, что истина где-то посередине. С одной стороны, конечно, прямая задача менеджера - мотивация сотрудников, отслеживание настроений, тим билдинг и т.п. и девелоперы абсолютно вправе ожидать всего этого от своего менеджера. С другой стороны, не стоит забывать о том, что всвязи с молодостью ИТ индустрии у нас практически никто не получает профессионального образования в сфере проектного менеджмента, а опыт 1-2 года уже считается существенным. Т.е. в большинстве своём менеджеры (кстати, как и разработчики!) - это самоучки, поэтому ожидать от них профессионально грамотного поведения не приходится. Корень проблемы - в перегретости ИТ рынка труда, где отыскать хорошего девелопера (кстати, как и менеджера)  - задача совсем не из простых. Отсюда и нежелание девелоперов идти навтречу менелжерам и упрощать им жизнь. Мол, "через дорогу" меня возьмут с удовольствием на таких условиях как я хочу без всяких "но" и "если". Я думаю, пока существует эта перегретость, ожидать что девелоперы будут очень утруждаться и помогать менеджеру догадаться о своих пожеланиях, не приходится. Только дождавшись стабилизации рынка можно ожидать что 1) менеджеры будут становиться всё более профессионально подготовленными и будут не просто "дрючить" девелоперов, а выполнять свои основные задачи, т.е. решать организационные проблемы проекта (среди которых проблема кадров - одна из первых); 2) разработчики перестанут раздуваться от собственной важности и востребованности от того что цена на их труд растёт как снежный ком и станут так же заинтересованными в своей компании, как и она в нём. Тогда и только тогда можно требовать тех "партнёрских" отшений между сотрудником и руководством, которые так хотелось бы наблюдать автору уже сейчас.

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Tuesday, August 26, 2008 7:13 AM
Permalink | Comments (3) | Post RSSRSS comment feed