Балмер, инновации, Скрам и Гитлер


Из интервью с главой Microsoft Стивом Балмером:

В завершение встречи, отвечая на вопрос «Эксперта Online», Балмер рассказал, почему Microsoft продолжает вкладывать средства в убыточное онлайн-направление. Это не потери, а инвестиции, уверен Балмер. Как признался руководитель Microsoft, в его корпорации тщательно изучали опыт работы компаний в период Великой депрессии. Они проанализировали 50 ведущих фирм тех времен. И в выигрыше оказались те, которые сократили издержки и вместе с тем не прекращали инвестиций в инновации. В частности, компания RCA, которая разрабатывала телевизор – новинку для того времени. «Сейчас этой компании больше не существует, так что это не идеальный пример для всех времен, но, по крайней мере, он доказывает, что инновации – это очень важная вещь», – сказал глава Microsoft. Проводя аналогию с настоящим, Балмер утверждает, что в течение четырех-шести лет произойдет очень много инноваций в онлайн-технологиях, и Microsoft, желая оставаться на коне, продолжит инвестировать в их развитие.


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

К счастью у нас в F-Secure это всё понимают. Старожилы удивляются и говорят, что следующий релиз, который будет уже летом, будет самым инновационным за все времена. Очень много изменений, нововведений, оптимизаций, учтенных пожеланий клиентов и т.п. Расходы, как и у всех, оптимизируются, но не за счет будущих релизов и новых продуктов.
Рад, что я тоже приложил немало своих усилий к этим изменениям в F-Secur-овских продуктах. Те, кто установил наш антивирус по-моему совету, увидят изменения уже через неделю-две, когда будет выложена очередная бета. Она на их компьютеры автоматически скачается и установится.

Надо сказать, что во многом такой успех отдела разработки связан с применением гибких технологий. Scrum, feature teams, continious integration, automated tests, многие даже практикуют юнит тесты и работы в парах - это позволяет, как и ожидалось, вносить изменения в продукт в разы быстрее, чем старые схемы работы с областями ответственности и “владельцами кода”. Сейчас код пишется, интегрируется в продукт и меняется гораздо быстрее и как-то даже качественнее.
Кстати, я уже пару месяцев, как назначен Scrum-мастером в нашей команде. Команда идеальная - все увлечены своим делом, работают сами и очень хорошо, проблем почти не бывает, так что Scrum-мастеру работы почти нет. Но зато у меня теперь есть официальное звание! :)


Ну, а для шутки юмора - как Гитлер внедрял Agile:



Понравилась статья? Подпишись на RSS!

8 комментариев к Балмер, инновации, Скрам и Гитлер

  • Андрей Светлов

    А какое отношение имеет парное программирование к юниттестам?
    И почему они только на последнем месте, после continious integration, automated tests?
    Как по мне - если юниттестов нет - говорить не о чем. Коммитишь код и ждешь следующего дня - может QA что-нибудь отпишет по результатам своей проверки (ибо у нас билд ежедневный).
    У нас так:
    - юниттесты обязательны. Если QA поймала то, что может покрываться юнитами - легкий втык и правка тестов.
    - билд-бот постоянно проверяет svn (да, мы его все еще используем и я не знаю когда переключимся полностью на dvcs)
    - если что-то заметил - прогоняет юниттесты. Ежели сломались - срочно чинить.
    - под вечер делается рабочий билд.
    - ночью он автоматически проверяется на QA.
    - утром QA team анализирует результат и на утреннем митинге высказывает свое “фи”.

    Эта схема тоже не решает все проблемы и можно делать лучше.

    Парное программирование опять же не панацея. Использую его только если нужно сотрудника “подтянуть” и объяснить ему генеральную линию партии. Иначе (в трудных ситуациях и при нехватке времени) - часто проще и быстрее сделать все самому (и объяснить результат изменений позже, пропустив мучительную часть выбора правильного решения).

    Review - опять же не всегда хорош. Либо я даю “добро” потому что или “сделано неплохо, а мои пожелания могут подождать” либо просто “оно ужасно, но таки работает - просто отвяжитесь, потом сам займусь, и с правильным человеком в паре”.

    • Юнит-тесты далеко не панацея, поэтому я их вначало списка и не поставил. Да и у нас от 100% покрытия юнит тестами очень далеко. Юнит тесты могут отлично помочь в едином цельном продукте. А в большом модульном продукте гораздо важнее иметь много system tests и regression tests. Очень много ошибок именно после соединения модулей, на разных ОС, с разными скоростями интернета и т.п. - их юнит тестами не поймать никак. А вот автоматический system test спасает - испортил, закомитил, билд создался автоматически, автоматически для него на разных ОС запустились system тесты и через 2-3 часа получил отчёт, если что-то испортил. В отчете будут логи и т.п. - вся инфа для исправления.

      Про review вообще не написал, хотя тоже используется. Раньше я был сторонник review, но постепенно пришёл к тому, что он бесполезен и только отвлекает. Но review кода начинающих программистов и новичков может быть полезен.
      Про своё отношение к парному программированию собираюсь отдельную статью написать - слишком неоднозначно я к нему отношусь. Иногда полезно, чаще вредно.

  • Андрей Светлов

    Ответ понравился.
    У нас тоже 100% покрытия тестами нет - хоть и гоняют за это дело. И продукт тоже далеко не цельный.
    Другой вопрос - я стараюсь следовать правилу:
    - QA поймала баг.
    - Поймай его на юниттесте. Иногда непросто. Напишу десятка два - а они лищь подтверждают - все работает как надо. На третьем десятке может прийти просветление. И радость: поймал скользкого гада, пришпилил его в юните и если опять появиться - юнит вовремя прокричит.
    - Почини, повтори QA и закомить все свои новые юниты. Явось в будущем заявят о себе (возможно не фиксируя баг но показывая, что ожидания разработчиков были неадекватны жизни. Тоже очень полезно).

    Регрессионных сейчас ровно двенадцать (и сотрудники ржали в голос над роликом).
    Они идут минут сорок - ибо довольно большие. И не всегда показывают ошибки - система сложнее.

    Полный QA stack выполняется за 4.5 часов. Поэтому запускается только ночью для тестирования ежедневного билда.
    Я не совсем понял, у вас system test (который у нас зовется QA) запускается на каждый commit? Или только на commit to trunk?
    И сколько у вас тестировочных машин, которые любое изменение подхватывают и каждая по 2-3 часа его тестирует?
    Наверное, все гораздо проще и я чего-то недопонял.
    Используете ли dvcs или старый добрый subversion? (далеко он не добрый, но у нас миграция затягивается).

    Про “Очень много ошибок именно после соединения модулей, на разных ОС, с разными скоростями интернета и т.п. - их юнит тестами не поймать никак.” могу сказать только: можно поймать, нужно только правильные моки сделать.
    Сегодня ловил такого гада. И поймал. На юнитах все было отлично. Regression чаще проходил, чем нет. После долгого вникания в ситуацию понял, почему оно так. Добавил юнит. Он тоже поломался. Починил код. Все заработало. Залил мои изменения.

    review, имхо, хорош. Когда ревьювер адекватный. Но только если смотритель - тоже отличный спец. И задает вопросы по теме, а не просит объяснить каждую деталь - и все равно ничего не понимает. В таком случае - напрасная трата времени.

    Пары хорощи при “затыке”. Или при объяснении правильного использования новой штуки. Повторять, пока другая сторона не “осознает”.

    В общем, для меня тоже спорные и неоднозначные вопросы.

    • Ух, как много информации и вопросов, спасибо :)
      Постараюсь ответить на все вопросы.
      1. Я не совсем понял, у вас system test (который у нас зовется QA) запускается на каждый commit?
      У нас есть инкрементальные версии продукта. Например, какой-то модуль изменился и хочет попасть в продукт. Он билдится и метится меткой “smoked” в SVN (да, у нас SVN и немного CVS). После этого билд система сразу строит новый продукт - целиком, прямо с инсталером. Через 5-10 минут уже готово. Далее есть очень мощная система автоматического системного тестирования. Она построена на WMVare - там несколько машин и десятки WMVare имейджей с разными ОС. Система тестирования туда устанавливает продукт и запускает тесты. Они репортят в базу данных и если что не так, то рассылают всем письма, кто виноват. У каждого тест кейза там свой адресат для писем, так что зафейлился файрвол - письмо придет именно автору файрвола :)
      Вот, примерно так.

      2.
      >> Про “Очень много ошибок именно после соединения модулей, на разных ОС, с разными скоростями интернета и т.п. - их юнит тестами не
      >> поймать никак.” могу сказать только: можно поймать, нужно только правильные моки сделать.

      Например как поймать это: у нас есть файрвол и антивирус. Причем они друг про друга вообще не знают и могут работать даже отдельными продуктами друг без друга - тот же самый билд. И, например, в антивирусе появился баг, который блокирует доступ к темповому файлу файрвола, который ему нужен и он начинает работать не так. Такое юнит-тестом не поймаешь :)

      3. review, имхо, хорош. Когда ревьювер адекватный.

      Мой пойнт в том, что ревью хорош, когда ревьювер адекватный, а исполнитель - не очень, то есть делает баги часто. Если же автор кода хорош, то ревью его кода даже хорошим ревьювером обычно - просто трата времени. Хотя иногда что-то находится, да.
      Например, из моего опыта: когда я ревьювил начинающих программистов, то находил у них каждый раз несколько багов. В то же время у опытных проф. программистов я находил 1 баг в 4-5 комитах. Стоит ли оно того?

  • konstantin

    самое забавное, что из перечисленого (autmated tests, feature teams etc) к гибким технологиям кроме самого Scrum - больше то ничего и не относится.

  • Artem

    У меня вопрос есть по F-Secure. Как раз именно по вашему совету я его установил. Но, к сожалению, простоял он на машине недолго: всего пол дня. Причиной удаления стал в том числе и интерфейс. Машина, на которой он был установлен, работает в сети. Программа заблокировала все соеднинения по внутренней сети и никакими настройками не позволяла зайти на машину из сети. Причём, даже выгрузка программы не освободила порты. Опять доступ появился только удаления и перезагрузки. Подозреваю, что я просто не разобрался с программой. Но надо было быстро, а интерфейс такой, что там было неочевидно, как отключить фаервол или что-то ещё, что может закрывать порты. Будут ли в новой версии какие-то изменения в этом плане? Возможно, я ещё раз попробую.

    • Да, в новой версии, точнее в финальной, которая летом выйдет, будет совершенно новый интерфейс. Там планируется одно меню, к котором будут все возможные действия. Например, “открыть порт”. Это должно быть очень просто.
      В текущей версии тоже, конечно, можно задизаблить файрвол через меню. Но, похоже, разобраться в этом непросто.

      • Artem

        Так в том-то и дело, что я фаервол дизейблил (упреждая вопрос: виндовый не включен) - не помогало. Мож просто не разобрался, конечно. С выходом новой версии ещё раз попробую, так как проблема выбора антивирусника имеется.
        Спасибо за ответ.

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>