Изменения

{{Conf-Ref}}Серия осенних конференций началась с [http://agilerussia.timepad.ru/event/83430/ AgileKitchen]. В конце месяца будет [http://2013.secr.ru SECR] с Иваром Якобсоном, потом - — [http://sqadays.com SQAdays] во Львове с отдельным днем европейских докладчиков, а в начале декабря - — [http://spmconf.ru/ SPMconf] в Казани. Это - — те, на которых я планирую быть, чтобы услышать, почувствовать новые тренды отрасли, узнать новые практики. И удачное начало этому было положено на AgileKitchen в эту пятницу, на территории Лаборатории Касперского.

Несмотря на название и позиционирование как обмен мнениями "на кухне"«на кухне», это было достаточно серьезное мероприятие. И по числу участников - — думаю, было около сотни, хотя могу ошибаться, — которые сидели в большом зале, объединенном из трех переговорных с тремя большими экранами, и по уровню организации. И, главное - — по характеру выступлений. На AgileKitchen выносятся темы, которые сейчас на острие развития, не успели обрасти серьезными теориями и практиками, но которые пробуют изучать и применять. И люди обмениваются опытом. А еще - — там делятся практическим опытом решения задач, которые почему-то не становятся менее актуальными, несмотря на, казалось бы, давно известные подходы к решению. Их решают в конкретных условиях, и каждое новое решение имеет свои особенности, дает какой-то новый опыт, который тоже интересно обсудить.

Собственно, обсуждение практического опыта - — самая важная составляющая мероприятия. И его было много - : в перерывах между докладами, на OpenSpace, после конференции. '''UPD. [https://www.evernote.com/shard/s9/sh/497612c3-ad1d-4dd9-8502-9c203f9f691f/47ce75f2cdd5143da419f50c1d64f0b9 Материалы конференции]'''

== Motivation 3.0 - : что вы должны знать для работы с командой - (Алексей Пименов ) == [https://youtu.be/4uaAxeFTVZ4 Видео]

Алексей Пименов работает в ФИНАМ. Он рассказывал об эволюции теории мотивации и исследованиях в этой области. О том, что правильная мотивация для творческих задач, которыми занимаются ИТ-шники - , возникает , когда ты находишься "в потоке"«в потоке». А это означает, что подходы, основанные на различных KPI и метриках - не уместны, — неуместны. Что особенно интересно - — он сумел рассказать это не только нам, программистам, которые "в теме"«в теме». Он сумел убедить в этом не-ИТ-менеджеров у себя в компании.

'''Мотивация 1.0''' - — нами управляют потребности. Пирамида Маслоу. Понятно, что для потребностей нужна система сдержек и противовесов, на случай противоречащих потребностей разных людей. И это ведет к следующей ступени.

'''Мотивация 2.0''' - Мы — мы стремимся к удовольствиям , избегая наказаний. А удовольствия и наказания отмеряются , по Тейлору, в научной организации труда. Что приводит к KPI и методу Кнута и Пряника.

У этой системы есть 7 фатальных изъянов. :* Могут могут гасить внутреннюю мотивацию;* Могут могут снижать эффективность;* Могут могут подавлять творчество;* Вытесняют вытесняют хорошее поведение;* Поощряют поощряют мошенничество, поиск легких путей, неэтичное поведение. Игра SLAka - — выдержать SLA у себя и скинуть так, чтобы соседи не выполнили ; * Могут могут вызывать привыкание;* Могут могут развивать косность мышления.

Более того, довольно давно проводились эксперименты, показывающие, что потребности и наказания вовсе не являются единственной и даже самой сильной движущей силой интеллектуальной деятельности. И не только у человека, но и у обезьян эксперименты . Эксперименты Гарри Харлоу в 1949 показали, что обезьяны разгадывают головоломки "просто так"«просто так», и добавление к этому элемента вознаграждения (изюм) увеличивает результат (ускоряет разгадывание) незначительно.

Дуглас МакГрегор в 1960 году в Human Side of Enterprise ввел понятие людей двух видов: X-person, которым нужен менеджер , и Y-person, которые увлечены сами.

А в 1969 Эдвард Леси на экспериментах с людьми, аналогичных опыту Харлоу показал, что добавление материальной мотивации убивает творческий процесс, который без нее - — развивается.

Так возникает '''Мотивация 2.1''' - — интегрируем в 2.0 МакГрегор.* Рутина Без разнообразия - без Разнообразия — Деньги. Признать, что рутинная, разрешить выбрать способ для компенсации.* Рутина с Разнообразием или НеРутина - — обеспечиваем условия, и работаем на самореализацию. Признание заслуг и прочее. Командное взаимодействие. А деньги всегда даем неожиданно - — иначе он будет пользоваться именно этим.

Возникает вопрос - — а что значит "обеспечить «обеспечить условия работы"работы»? Отчасти ответ дает двухфакторная теория мотивации Герцберга - — надо обеспечить гигиенические факторы. Но этого недостаточно.

В 1990 появилась работа Михай Чиксентмихайи. Мысль, что "мы «мы проживаем жизнь неправильно"неправильно». У человека есть состояние потока, в котором индивид может направлять внимание на свои цели, потому что не надо бороться с отвлечением внимания и угрозам. Состояние потока - — единение с деятельностью и ситуацией. И так возникла '''Мотивация 3.0''' - — мы стимулируем участие, естественное желание работать путем переживания потока.

Правда, готовых рецептов тут нет. Речь идет об индивидуальной работе. Потому что состояние потока возможно, когда человек увлечен, а еще - — когда он находится в допустимом коридоре по осям Требования - — Умения. Потому что , когда Требования > Умений = Тревога, а Умения > Требований = Скука.

Но есть правилатого, что помогает, и что мешает. Помогает.:* Ясность ясность в отношениях - — знаете, что хотят;* Интерес интерес руководителя, что думает и чувствует подчиненный, а не только к прогрессу задачи;* Предоставление предоставление возможности выбора и принятие ответственности за него* Чувство чувство общности (поддержка, ценности);* НЛП-шное якорение. Один раз войдя в состояние - , повесить якорь и научиться входить туда же. Правда он не умеет, но про инструмент - — знаетAgile содержит много практик, которые работают именно в этих направлениях - : обратная связь, ценностная модель, совместная деятельность.

Что мешает.:* Психическая не предрасположенность - — шизофреники.* СоциальноСоциальный фактор. Отсутствие правил - — неясно, что можно; Неяснонеясно, что нужно. Состояние отчуждения .* Личные патологии. Невозможность концентрироваться (может , и врожденная). Чрезмерная сосредоточенность на себе (эгоцентризм, личная выгода).И если сопоставить эти списки с KPI и подобными подходами Мотивации 2.1, то ясно, что они - — скорее мешают, чем помогают.

На этом - — все. Но тема - интересная. От себя хочу добавить, что есть известная книга Мифы Мотивации «Мифы мотивации» Шпренгера, в которой он показывает, как мотивация 2.0 (бонусы и прочие изобретения) приводят в тупик в долгосрочной перспективе даже для продавцов.

== Игрофицированный менеджмент - (Коробцев Максим, GameTrek ) ==

Максима я слышал на AgileDays, где тоже делал доклад про gamificationGamification. По-русски это называли как "геймификация"«геймификация», однако слово имеет всякие неправильные оттенки, поэтому теперь Максим предпочитает полную русификацию термина.

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

Игрофикация - — игровая значимость реальных рабочих активностей. И она помогает работе за счет увдечения увлечения людей, а еще - за счет того, что доносит через игровую форму в игровой форме до людей правильные приоритеты. потому Потому что нет проблемы нехватки времени, есть только проблема неверной расстановки приоритетов.

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

Вторая игра "Коробки"«Коробки», ее запускают для Одноклассников. Цель - — устранить технический долг, обеспечить исправление мелких ошибок, за которые берутся неохотно. Идея - — каждый месяц вываливается "ящик Пандоры" - «ящик Пандоры» — коробка ошибок для устранения за заданное время "разбора коробки"«разбора коробки». Ошибки - персонифицированы— персонифицированные, ты помогаешь конкретному пользователю с его проблемой. А еще - — нарабатываешь скилы. При этом техника прохождения может быть различной, можно соревноваться в количестве - — тогда люди будут брать то, что хорошо умеют, а можно - — через "чек«чек-пойнты"пойнты», разнородные ошибки. , если хотим прокачивать кроссфункциональность.

Еще есть игра NASA «NASA против космической угрозыугрозы». Когда всякая проблема визуализируется как комета на землю, приближающаяся к Земле, а дальше рабочая группа должна образоваться и с ней справляться, и это - — видно.

Как видно, большинство этих техник - — они нацелены на решение рутинных или вспомогательных задач, наряду с основной интересной работой.

И принципиально: игра - — '''не''' обязательно. Но люди - — вовлекаются по классической кривой вовлечения.

== Right Team: Баланс и Резонанс взаимодействия - (Майк Рыжиков ) ==

В целом в фундаменте командного взаимодействия лежат три вещи:* Лидерство;* Единая Система ценностей;* Единый профессиональный контекст.Однако, в докладе о них подробно не говорили. Просто о них - надо помнить, говоря о команде. А предметом выступление было выстраивание взаимодействия.

* Balance 1+1=2. Сильные стороны дополняют друг друга. Надо знать сильные и слабые стороны свои и других. Но! часто есть недооценка или переоценка сторон и с этим надо работать. Например, тренер, оценивающий. Зона применения - — исполнение в рамках понятной концепции.* Resonance 1+1 > 2. Резонирующее - — совпадение частот. Гармонизация целей, гармонизация контекста, очередность (у солистов резонанса не будет). Зона применения - — генерация идей, надо раскачивать друг друга.

Организованное взаимодействие:* Создание точек взаимодействия;* Самоанализ и взаимоанализ;* Тренер и Тренировочный процесс;* Фасилитация и Ритуалы;* Ретроспективы для взаимодействия;

В целом , мысли понятные и важные, но по кейсам уровень - — не слишком высокий. Потому что у них стабильная многолетняя сложившаяся команда с двумя лидерами - — организационным и техническим. Это - самая простая конструкция. Хотя, нельзя сказать, что раз она простая - — ее просто построить. Далеко не всем это удается, и удачный опыт - — ценный. А сложившаяся она - — сейчас, они выходят на Performing. На этапе Storming было непросто. А на OpenSpace Майк делился опытом решения проблем.

== OMG SEMAT — единая теория программной инженерии - (Юрий Куприянов ) ==

Это доклад о новом продукте SEMAT (Software engineering method Engineering Method and theoryTheory) - — Essence of Software Engineering: Kernel and Language. Я о нем знаю из разных источников, поэтому указанное в описании доклада , услышанное на докладе и узнанное ранее будет перемежаться. А еще - — после доклада было много обсуждений, и часть мыслей - оттуда.

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

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

Как идея все это звучит хорошо. Но вызывает опасения, что опять получится нечто громоздкое и слабоприменимое. Глава рабочей группы, которая все это создала - , — Ивар Якобсон, — один из создателей UML и RUP. И с этим тоже связаны опасения. UML в простых проявлениях - — используется много, а вот как полноценный язык - — не очень. А на смену RUP как раз и пришел agileAgile. Но, смотря глядя на результат сейчас - , можно сказать — он вдохновляет на использование. Он очень свежий, появился только в этом году, поэтому о полноценном использовании пока говорить рано. Но его пробуют применить в своих проектах. А еще - — в обучении, и там он оказался весьма эффективен, потому что позволяет связать все аспекты деятельности в единое целое, и дает пути, по которым можно пробовать идти без практического опыта ведения проектов, наполняя содержанием своего модельного или реального проекта.

В докладе был краткий обзор Essence и источников, а практический опыт как раз больше касался знакомства, собственных попыток применить применения и обучения.

Обзор я совсем кратко повторю. Для начала - — терминология. Она во многом оригинальная, и это авторами сделано сознательно. Оригинальная она там, где использование существующих терминов вызывало бы нежелательные коннотации, связанные с применением термина в рамках существующих методологий и процессов и привела бы к потере существенных оттенков смысла. Там, где этого нет - , — брали существующий термин, поэтому, например, customer Customer и stakeholder - Stakeholder — остались. Зато появились Alpha и Endeavor.

* Предметы - это альфы и их экземпляры, рабочие продукты.;* Деятельность, activity space.Activity Space;* B Competence.

Альфа, для которой придумана расшифровка Abstract Level of Progress Health Attribute - — это очень абстрактное понятие. Это нечто, что имеет состояния, по изменению которого мы можем судить о продвижении (progressProgress) или здоровье (healthHealth) нашей деятельности. И это - — идеальный предмет, тип, у которого в реальности возникают экземпляры (instanceInstance) - — это рабочие продукты (Work Product). Альфы имеют последовательность состояний, с состоянием связан набор признаков (check listCheck List), которые должны быть зафиксированы для того, чтобы альфа его получила. И связана разнообразными ассоциациями с другими альфами. Деятельность - — совершается над экземпляром альфы - — рабочим продуктом - — или несколькими, и что-то в них изменяет, в результате они могут изменить свои состояния. А компетенции - — это способность определенные действия производить. Это если совсем кратко на абстрактном уровне.

На конкретном уровне программной инженерии все поле альф делится на три области: .* Customer - — это окружающий мир, заказчики и интересанты.* Solution - — это решение, предмет-результат деятельности, программная система. * Endeavor - — это сама деятельность. В этом месте ранее употребляли слово "Проект"«Проект», однако Essence описывает деятельность на полном жизненном цикле, а на этапе эксплуатации проекты занимают весьма ограниченное место. Говорят, в рабочей группе SEMAT есть представитель, занимающийся эксплуатацией , и она тщательно вымарывает слово "проект" по «проект»по площади.

И Essence говорит, что для описания создания софта вам потребуется в этих областях минимально 7 (семь) альф. :* Возможности (Oportunity) и Стейкхолдеры в окружающем мире;* Требования и Програмная система (Software System) в области решения;* Работы (Work), Технологии работы (wayWay-of-workWork) и Команды в Endeavor.Больше - — можно. И можно описывать подтипы. Но вот меньше - — нельзя.

Дальше для всех основных альф описаны состояния - — на полном жизненном цикле. Например, для стекйкхолдеров это Выявлены - Представлены - Вовлечены - В согласии - Удовлетворены развертыванием - Удовлетворены работой системы. Обратите внимание на два последних - : это - тоже состояния стейкхолдеров. И, естественно, помимо прямого пути возможен откат по графу. Состояние фиксируется для каждого отдельного стейкхолдера или для каких-то групп персонификаций, для всех вместе - — как вы построили свое описание.

И это образует Kernel - — ядро программной инженерии. Включая карточки чек-листов для состояний. А дальше есть библиотека - — описания имеющихся практик и методов. На языке и в понятиях ядра описаны распространенные методы Scrum, User Story и Multi-phase Phase Waterfall, показано, как выстраиваются комбинации, описаны расширения базовых альф для бизнес-анализа, разработки и управления задачами, и так далее. Например, в расширении для бизнес-анализа наряду с Возможностями и Требованиями появляются Нужды (Need), которые становятся механизмом для движения Возможностей по состояниям. Авторы утверждают, что все известные методы создания и сопровождения программных систем являются комбинацией из менее чем 250 практик. Число большое, но обозримое. И все их можно описать в предложенном формализме и, более того, они это сделают. В обсуждении доклада неоднократно всплывали методы ITIL, их формализации пока вроде не видели (что не означает, что их нет).

Кроме [http://www.omg.org/spec/Essence/1.0/Beta1/PDF/ текста стандарта], который достаточно сух, есть книга Ивара — Essence, которая более нацелена на практическое применение. Там есть практические кейсы, при чем причем в вариантах, пригодных как организации обучения с передачей сути, так и для постановки формального процесса, понимаемого через деятельность. При масштабировании надо и то и другое - , обучение через деятельность - — гораздо более быстрое, и понимание сути не является необходимым для всех.

На сайте Ивара http://www.ivarjacobson.com/ доступно описания практик, а также [http://www.ivarjacobson.com/SEMAT_Kernel_Cards_Download/ готовые карточки] чек-листов. В русском пространстве метод активно осваивает Анатолий Левенчук, публикуя посты [http://ailev.livejournal.com/ в своем блоге], одновременно адаптируя и расширяя метод на системную инженерию. Он полагает, что это - — определенный прорыв и именно в силу простоты изложения и формализма, не взирая на сопутствующие этому ограничения. У него есть перевод терминологии, и сделан перевод карточек. Параллельно и взаимодействуя работает русское отделение SEMAT, которое тоже ведет перевод стандарта и книги Ивара. Словарь доступен [http://goo.gl/zfyzjt здесь], работа идет в тесном контакте с основным SEMAT.

С готовыми артефактами библиотеки и связано возможное применение стандарта сразу. Вы можете просто распечатать карточки и читать их, сравнивая с ними свой процесс. Как сказал Юрий, сначала есть ощущение, что читаешь очевидные и известные вещи - , пока не добираешься до пунктов, о которых сам почему-то не задумывался :) И часть этих пунктов можно сразу применять, и в работе и даже включая в договора. Юра так уже делал. Конечно, такой договор сложнее заключить, но по нему легче работать. Более того, ему уже реально приходилось апеллировать к этому в разборках. При чем отношения с Заказчиком заказчиком сохранились, и даже увеличилось уважение со стороны заказчика, а еще тот начал договора читать :)

А еще карточки можно применять в обучении, и это Юра тоже делал на Физтехе. Потому что в разных курсах студентам дают различные составляющие процесса создания ПО, а комплексная картинка не возникает. Карточки позволяют ее сложить, при чем причем сразу в достаточно конкретном виде, пригодном для того, чтобы двигать свой проект.

За дальнейшими ссылками и содержанием отсылаю к [http://www.slideshare.net/YuryKupriyanov/semat-agile-russia слайдам Юры], которые он уже выложил. А в обсуждении , откуда начать знакомиться , возникла идея, что тут неплохо сработает обучение бросанием в воду. Берешь один из последних постов Левенчука, например, [http://ailev.livejournal.com/1083339.html этот] и копаешь по ссылкам в прошлое и на стандарты, пока не станет понятным. А на SECR можно будет не только услышать Ивара, но и пообщаться с ним [http://2013.secr.ru/lang/ru/program/open-discussion-corner в дискуссионном уголке].

== Опыт применения A3 в компании Skype - (Алексей Ильичев ) ==

A3-анализ — это подход к решению стратегических проблем, применявшийся в Тойоте«Тойоте». Суть его в том, что под одну проблему заводится лист формата А3, на котором коротко изложена суть проблемы, анализ и контр-меры. Алексей рассказывал о том, как в компании Skype они пробуют применять этот метод на трех практических кейсах.

Кейсы: проблемы с дизайнерами, из-за запаздывания работы которых возникали сложности с релизами, проблема с разрешением на использование open source Opensource-библиотек и организация работы с QuickBuild.

Сразу скажу, что во всех случаях проблемы решались просто от их осознания и обсуждения. В случае с opensource Opensource вообще оказалось, что ответственные лица готовят документ, и через полгода будет счастье. Только ситуация была такова, что полгода ждать было нельзя и нужно было временное решение, и проведенный анализ как раз обосновывал остроту ситуации. Подробно описывать кейсы я не буду, интересующиеся могут посмотреть запись, когда она появится.

Практически формат использовался как '''решение проблемы снизу''', в любом месте, где она возникает. Роль формата А3 в том, что при этом любой сотрудник, заинтересованный в проблеме, но не имеющий навыка решения, получает форму, следуя которой он может продвигаться, обсуждая проблему на всех уровнях и получая доказательную базу для обсуждения с руководством. Я знаю, что этого - часто не хватает: тот, у кого болит - , — не знает , как подступиться к проблеме, а тот, кто это умеет - , — занят реально более важными вещами, да и донести важность проблемы у него не получается.

Шаблон А3 есть в инетеИнете, они брали уже как-то адаптированный из книги Тома Поппендик и Генриха Книберга. А3 Problem Solving Template. Важно, что заполнять его надо так, чтобы понял генеральный директор (условно), а не техническим сленгом - , — тогда с высокой вероятностью поймут все, с кем будете обсуждать. Начинали они с реально бумажного шаблона, и пока ты в пределах офиса , бумага с карандашом для обсуждений - — удобнее. Но у них много офисов разработки , и с выходом за пределы офиса они переходили в викиWiki, и там же рисовали графы root cost analysisRoot Cost Analysis, расшаривая рабочий стол при обсуждении.

== Теория Ограничений для ИТ: информационные ограничения и управление временем - (Андрей Степенко ) ==

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

В качестве позитивных примеров, как эти ограничения можно обойти, приводились open source Opensource проекты, в которых система принятия решений распределена. Правда, без подробностей внутреннего устройства. Но с общим тезисом, что это так происходит, потому, что там люди увлечены делом, и сознание находится в согласии с деятельностью. А еще ум расслаблен и незашоренне зашорен. И с этого места Андрей перешел к тому, что есть такая техника - — цигун - — которая позволяет расслабляться и приводить сознание в спокойное и эффективное состояние. Нам немного про цигун рассказали, а потом были практические занятия. Прикольно. Но, по -моему, не по делу. Может, потому, что я и так хорошо прихожу в эффективное рабочее состояние...

А кроме цигуна Андрей еще сказал, что есть такой GTD Аллена. Одним из эффектов которого - является достижение бесстрессового состояния, что тоже повышает результативность мышления.

А еще на конференции было два практических кейса, касающися касающихся документации.

== Гибкая разработка пользовательской документации - (Сергей Рогачев ) ==

Проблема документирования - — известно-плохо-решаемая. Ребята применили известные подходы - — включение в итерации, включение в DoD для userstory Userstory и трассировка фичи-документациядокументации. И у них заработало.

Что интересно в докладе - — достаточно подробные документы, как у них организовано. Например, в описании DoD указано, что именно надо не забыть поправить (типа, часто Title забывают поправить), а отдельно - какие — каковы самые частые нарушения. Трассировку делали через автосборку на TFS из Word. И приведенные примеры покрывают не только документирование - , поскольку оно тесно связано с остальным процессом. А заглянуть в организацию процесса у других - — всегда интересно. , можно почерпнуть новые идеи.

И они поделились отдельным инструментом, который они используют. TeamSolution TeamSpec - — плагин к VS. Они сделали отдельный WorkItem Document Item и именно там пишут документацию. Плагин это собирается в Word, а еще позволяет там редактировать с сохранением изменений в исходный Document Item.

== Разрушители мифов: Agile и аутсорс - аутсорс» (Инга Юрьева ) ==

В докладе рассказывалось о процессах документирования и локализации в Лаборатории Касперского. Проблема возникла после того, как они вышли на международный рынок. И основная версия выходит на 6-8 языках, а через 2-3 недели - — еще 30-50 дополнительных языков. Работы по локализации были переданы из отдела в отдел документирования. При этом разработка, естественным образом, часто идет до последних дней, но документацию и локализацию надо успеть сделать. Еще одна особенность - — в работе участвует достаточно много внешних сотрудников, поскольку для хорошего перевода нужно редактирование носителями языка.

Процесс был первоначально построен под водопадную разработку. А потом, с внедрением agile Agile в разработке - — перестроен с его учетом. Правда, их пугали - , что agile Agile и аутсорс несовместим, и качество упадет ниже допустимого. Но реально agile Agile повлиял не слишком - — из-за того, что разработка велась до последних дней, многое в процессе уже было. Но вы в целом было рассказано достаточно много подробностей и особенностей, касающихся построения процесса. А основа успеха - — тщательный подбор персонала по soft skill - Soft Skill — культуре, коммуникациям, мотивации... И внешних сотрудников они держат на постоянной основе, перейдя от аутсорса к аутстафу.

{{wl-publish: 2013-10-12 22:3219:35 +0400 | MaksTsepkov }}[[Категория:Конференции]]