Изменения

Блог:Максима Цепкова/2013-10-12: Впечатления с AgileKitchen

645 байтов добавлено, 20:24, 26 апреля 2017
м
Motivation 3.0: что вы должны знать для работы с командой (Алексей Пименов)
{{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. Резонирующее - совпадение частот. Гармонизация целей, гармонизация контекста, очередность (у солистов резонанса не будет). Зона применения - генерация идей, надо раскачивать друг друга.
* Anticooperation 1+1 < 2. Его, понятно, надо устранять.
Организованное взаимодействие:* Создание точек взаимодействия;* Самоанализ и взаимоанализ;* Тренер и Тренировочный процесс;* Фасилитация и Ритуалы;* Ретроспективы для взаимодействия;
* Работа в парах, Коллективное принятие решений.
В целом , мысли понятные и важные, но по кейсам уровень - не слишком высокий. Потому что у них стабильная многолетняя сложившаяся команда с двумя лидерами - организационным и техническим. Это - самая простая конструкция. Хотя, нельзя сказать, что раз она простая - ее просто построить. Далеко не всем это удается, и удачный опыт - ценный. А сложившаяся она - сейчас, они выходят на Performing. На этапе Storming было непросто. А на OpenSpace Майк делился опытом решения проблем.
= Методы: SEMAT, А3 и теория ограничений =
== 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 — это очень абстрактное понятие. Это нечто, что имеет состояния, по изменению которого мы можем судить о продвижении (Progress) или здоровье (Health) нашей деятельности. И это — идеальный предмет, тип, у которого в реальности возникают экземпляры (Instance) — это рабочие продукты (Work Product). Альфы имеют последовательность состояний, с состоянием связан набор признаков (Check List), которые должны быть зафиксированы для того, чтобы альфа его получила. И связана разнообразными ассоциациями с другими альфами. Деятельность — совершается над экземпляром альфы — рабочим продуктом — или несколькими, и что-то в них изменяет, в результате они могут изменить свои состояния. А компетенции — это способность определенные действия производить. Это если совсем кратко на абстрактном уровне.
Альфа, для которой придумана расшифровка Abstract Level of Progress Health Attribute - На конкретном уровне программной инженерии все поле альф делится на три области.* Customer — это очень абстрактное понятие. Это нечтоокружающий мир, что имеет состояния, по изменению которого мы можем судить о продвижении (progress) или здоровье (health) нашей деятельностизаказчики и интересанты. И * Solution — это решение, предмет- идеальный предметрезультат деятельности, тип, у которого в реальности возникают экземпляры (instance) - программная система. * Endeavor — это рабочие продукты (Work Product)сама деятельность. Альфы имеют последовательность состоянийВ этом месте ранее употребляли слово «Проект», с состоянием связан набор признаков (check list)однако Essence описывает деятельность на полном жизненном цикле, которые должны быть зафиксированы для того, чтобы альфа его получилаа на этапе эксплуатации проекты занимают весьма ограниченное место. И связана разнообразными ассоциациями с другими альфами. Деятельность - совершается над экземпляром альфы - рабочим продуктом - или несколькимиГоворят, и что-то в них изменяетрабочей группе SEMAT есть представитель, в результате они могут изменить свои состояния. А компетенции - это способность определенные действия производить. Это если совсем кратко на абстрактном уровнезанимающийся эксплуатацией, и она тщательно вымарывает слово «проект»по площади.
На конкретном уровне программной инженерии все поле И Essence говорит, что для описания создания софта вам потребуется в этих областях минимально 7 (семь) альф делится на три области: * Customer - это окружающий мир, заказчики Возможности (Oportunity) и интересанты.Стейкхолдеры в окружающем мире;* Solution - это решение, предмет-результат деятельности, программная Требования и Програмная система. (Software System) в области решения;* Работы (Work), Технологии работы (Way-of-Work) и Команды в Endeavor - это сама деятельность. В этом месте ранее употребляли слово "Проект", однако Essence описывает деятельность на полном жизненном цикле, а на этапе эксплуатации проекты занимают весьма ограниченное местоБольше — можно. Говорят, в рабочей группе SEMAT есть представитель, занимающийся эксплуатацией и она тщательно вымарывает слово "проект" по площадиИ можно описывать подтипы. Но вот меньше — нельзя.
И Essence говорит, что Дальше для описания создания софта вам потребуется в этих областях минимально 7 (семь) всех основных альфописаны состояния — на полном жизненном цикле. * Возможности (Oportunity) и Стейкхолдеры в окружающем мире* Требования и Програмная система (Software System) в области решения* Работы (Work)Например, Технологии работы (wayдля стекйкхолдеров это Выявлены -ofПредставлены -work) и Команды в Endeavor.Больше Вовлечены - можноВ согласии - Удовлетворены развертыванием - Удовлетворены работой системы. Обратите внимание на два последних: это тоже состояния стейкхолдеров. И можно описывать подтипы, естественно, помимо прямого пути возможен откат по графу. Но вот меньше Состояние фиксируется для каждого отдельного стейкхолдера или для каких- нельзято групп персонификаций, для всех вместе — как вы построили свое описание.
Дальше И это образует Kernel — ядро программной инженерии. Включая карточки чек-листов для всех основных альф состояний. А дальше есть библиотека — описания имеющихся практик и методов. На языке и в понятиях ядра описаны состояния распространенные методы Scrum, User Story и Multi- на полном жизненном циклеPhase Waterfall, показано, как выстраиваются комбинации, описаны расширения базовых альф для бизнес-анализа, разработки и управления задачами, и так далее. Например, в расширении для стекйкхолдеров это Выявлены - Представлены - Вовлечены бизнес- В согласии - Удовлетворены развертыванием - Удовлетворены работой системыанализа наряду с Возможностями и Требованиями появляются Нужды (Need), которые становятся механизмом для движения Возможностей по состояниям. Обратите внимание на два последних - это - тоже состояния стейкхолдеровАвторы утверждают, что все известные методы создания и сопровождения программных систем являются комбинацией из менее чем 250 практик. Число большое, но обозримое. Ивсе их можно описать в предложенном формализме и, естественноболее того, помимо прямого пути возможен откат по графуони это сделают. Состояние фиксируется для каждого отдельного стейкхолдера или для каких-то групп персонификацийВ обсуждении доклада неоднократно всплывали методы ITIL, для всех вместе - как вы построили свое описаниеих формализации пока вроде не видели (что не означает, что их нет).
И это образует Kernel - ядро программной инженерииКроме [http://www. Включая карточки чек-листов для состоянийomg. А дальше есть библиотека - описания имеющихся практик и методовorg/spec/Essence/1. На языке и в понятиях ядра описаны распространенные методы Scrum0/Beta1/PDF/ текста стандарта], User Story и Multi-phase Waterfallкоторый достаточно сух, показаноесть книга Ивара — Essence, как выстраиваются комбинациикоторая более нацелена на практическое применение. Там есть практические кейсы, описаны расширения базовых альф для бизнес-анализапричем в вариантах, разработки и управления задачамипригодных как организации обучения с передачей сути, и так далее. Например, в расширении для бизнес-анализа наряду с Возможностями и Требованиями появляются Нужды (Need), которые становятся механизмом для движения Возможностей по состояниям. Авторы утверждаютпостановки формального процесса, что все известные методы создания и сопровождения программных систем являются комбинацией из менее чем 250 практикпонимаемого через деятельность. Число большое, но обозримое. И все их можно описать в предложенном формализме При масштабировании надо ито и другое, обучение через деятельность — гораздо более тогобыстрое, они это сделают. В обсуждении доклада неоднократно всплывали методы ITIL, их формализации пока вроде и понимание сути не видели (что не означает, что их нет)является необходимым для всех.
Кроме [На сайте Ивара http://www.omgivarjacobson.orgcom/specдоступно описания практик, а также [http:/Essence/1www.0ivarjacobson.com/Beta1SEMAT_Kernel_Cards_Download/PDFготовые карточки] чек-листов. В русском пространстве метод активно осваивает Анатолий Левенчук, публикуя посты [http:/ текста стандарта/ailev.livejournal.com/ в своем блоге], который достаточно сух, есть книга Ивара Essence, которая более нацелена одновременно адаптируя и расширяя метод на практическое применениесистемную инженерию. Там есть практические кейсыОн полагает, при чем что это — определенный прорыв и именно в вариантах, пригодных как организации обучения с передачей сути, так силу простоты изложения и для постановки формального процессаформализма, понимаемого через деятельностьне взирая на сопутствующие этому ограничения. При масштабировании надо У него есть перевод терминологии и то сделан перевод карточек. Параллельно и другое - обучение через деятельность - гораздо более быстроевзаимодействуя работает русское отделение SEMAT, которое тоже ведет перевод стандарта и понимание сути не является необходимым для всехкниги Ивара. Словарь доступен [http://goo.gl/zfyzjt здесь], работа идет в тесном контакте с основным SEMAT.
На сайте Ивара 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 в дискуссионном уголке].
За дальнейшими ссылками и содержанием отсылаю к [http://www.slideshare.net/YuryKupriyanov/semat-agile-russia слайдам Юры], которые он уже выложил. А == Опыт применения A3 в обсуждении откуда начать знакомиться возникла идея, что тут неплохо сработает обучение бросанием в воду. Берешь один из последних постов Левенчука, например, [http://ailev.livejournal.com/1083339.html этот] и копаешь по ссылкам в прошлое и на стандарты, пока не станет понятным. А на SECR можно будет не только услышать Ивара, но и пообщаться с ним [http://2013.secr.ru/lang/ru/program/open-discussion-corner в дискуссионном уголке]. компании Skype (Алексей Ильичев) ==
== Опыт применения A3 -анализ — это подход к решению стратегических проблем, применявшийся в компании Skype «Тойоте». Суть его в том, что под одну проблему заводится лист формата А3, на котором коротко изложена суть проблемы, анализ и контр- меры. Алексей Ильичев ==рассказывал о том, как в компании Skype они пробуют применять этот метод на трех практических кейсах.
A3-анализ — это подход к решению стратегических проблем, применявшийся в Тойоте. Суть его в том, что под одну проблему заводится лист формата А3, на котором коротко изложена суть Кейсы: проблемыс дизайнерами, анализ и контриз-меры. Алексей рассказывал о томза запаздывания работы которых возникали сложности с релизами, как в компании Skype они пробуют применять этот метод проблема с разрешением на трех практических кейсахиспользование Opensource-библиотек и организация работы с QuickBuild.
Кейсы: Сразу скажу, что во всех случаях проблемы решались просто от их осознания и обсуждения. В случае с дизайнерамиOpensource вообще оказалось, из-за запаздывания работы которых возникали сложности с релизамичто ответственные лица готовят документ, проблема с разрешением на использование open source библиотек и организация работы с QuickBuildчерез полгода будет счастье. Только ситуация была такова, что полгода ждать было нельзя и нужно было временное решение, и проведенный анализ как раз обосновывал остроту ситуации. Подробно описывать кейсы я не буду, интересующиеся могут посмотреть запись, когда она появится.
Сразу скажуПрактически формат использовался как '''решение проблемы снизу''', в любом месте, где она возникает. Роль формата А3 в том, что во при этом любой сотрудник, заинтересованный в проблеме, но не имеющий навыка решения, получает форму, следуя которой он может продвигаться, обсуждая проблему на всех случаях проблемы решались просто от их осознания уровнях и получая доказательную базу для обсуждения. В случае с opensource вообще оказалосьруководством. Я знаю, что ответственные лица готовят документэтого часто не хватает: тот, и через полгода будет счастье. Только ситуация была таковау кого болит, что полгода ждать было нельзя и нужно было временное решение— не знает, и проведенный анализ как раз обосновывал остроту ситуации. Подробно описывать кейсы я не будуподступиться к проблеме, интересующиеся могут посмотреть записьа тот, когда она появитсякто это умеет, — занят реально более важными вещами, да и донести важность проблемы у него не получается.
Практически формат использовался как '''решение проблемы снизу''', Шаблон А3 есть в любом местеИнете, где она возникаетони брали уже как-то адаптированный из книги Тома Поппендик и Генриха Книберга. Роль формата А3 в томProblem Solving Template. Важно, что при этом любой сотрудникзаполнять его надо так, заинтересованный в проблемечтобы понял генеральный директор (условно), но а не имеющий навыка решениятехническим сленгом, получает форму— тогда с высокой вероятностью поймут все, следуя которой он может продвигатьсяс кем будете обсуждать. Начинали они с реально бумажного шаблона, обсуждая проблему на всех уровнях и получая доказательную базу для обсуждения пока ты в пределах офиса, бумага с руководствомкарандашом для обсуждений — удобнее. Я знаю, что этого - часто не хватает: тот, Но у кого болит - не знает как подступиться к проблемених много офисов разработки, а тоти с выходом за пределы офиса они переходили в Wiki, кто это умеет - занят реально более важными вещамии там же рисовали графы Root Cost Analysis, да и донести важность проблемы у него не получаетсярасшаривая рабочий стол при обсуждении.
Шаблон А3 есть в инете, они брали уже как-то адаптированный из книги Тома Поппендик == Теория Ограничений для ИТ: информационные ограничения и Генриха Книберга. А3 Problem Solving Template. Важно, что заполнять его надо так, чтобы понял генеральный директор управление временем (условноАндрей Степенко), а не техническим сленгом - тогда с высокой вероятностью поймут все, с кем будете обсуждать. Начинали они с реально бумажного шаблона, и пока ты в пределах офиса бумага с карандашом для обсуждений - удобнее. Но у них много офисов разработки и с выходом за пределы офиса они переходили в вики, и там же рисовали графы root cost analysis, расшаривая рабочий стол при обсуждении. ==
== Теория Ограничений для ИТ: Это был весьма странный и неожиданный доклад. Начался с того, что кроме физических ограничений, которые надо учитывать, используя теорию ограничений, существуют информационные ограничения . И в результате проекты с большим бюджетом не могут быть сделаны, потому что процедура принятия решений оказывается долгой и управление временем становится узким горлом. Правда, с мест качали, что, может это тоже физическое ограничение, связанное с отсутствием способных людей. Но, все- Андрей Степенко ==таки, по разным причинам так может быть.
Это был весьма странный и неожиданный доклад. Начался с тогоВ качестве позитивных примеров, что кроме физических ограниченийкак эти ограничения можно обойти, которые надо учитыватьприводились Opensource проекты, используя теорию ограниченийв которых система принятия решений распределена. Правда, существуют информационныебез подробностей внутреннего устройства. И в результате проекты Но с большим бюджетом не могут быть сделаныобщим тезисом, что так происходит, потому что процедура принятия решений оказывается долгой там люди увлечены делом и становится узким горломсознание находится в согласии с деятельностью. Правда, А еще ум расслаблен и не зашорен. И с мест качалиэтого места Андрей перешел к тому, чтоесть такая техника — цигун — которая позволяет расслабляться и приводить сознание в спокойное и эффективное состояние. Нам немного про цигун рассказали, может это тоже физическое ограничение, связанное с отсутствием способных людейа потом были практические занятия. Прикольно. Но, всепо-таки моему, не по разным причинам делу. Может, потому, что я и так может бытьхорошо прихожу в эффективное рабочее состояние...
В качестве позитивных примеров, как эти ограничения можно обойти, приводились open source проекты, в которых система принятия решений распределена. Правда, без подробностей внутреннего устройства. Но с общим тезисом, что это потому, что там люди увлечены делом, и сознание находится в согласии с деятельностью. А кроме цигуна Андрей еще ум расслаблен и незашорен. И с этого места Алексей перешел к томусказал, что есть такая техника - цигун - которая позволяет расслабляться и приводить сознание в спокойное и эффективное состояниетакой GTD Аллена. Нам немного про цигун рассказали, а потом были практические занятия. Прикольно. Но, по моему, не по делу. Может, потомуОдним из эффектов которого является достижение бесстрессового состояния, что я и так хорошо прихожу в эффективное рабочее состояние..тоже повышает результативность мышления.
А кроме цигуна Алексей еще сказал, что есть такой GTD Аллена[https://www. Одним из эффектов которого - достижение бесстрессового состояния, что тоже повышает результативность мышленияmindmeister. com/ru/335748479/ Mind Map доклада]
= Разработка документации =
А еще на конференции было два практических кейса, касающися касающихся документации.
== Гибкая разработка пользовательской документации - (Сергей Рогачев ) ==
Проблема документирования - известно-плохо-решаемая. Ребята применили известные подходы - включение в итерации, включение в 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 }}[[Категория:Конференции]]