|
2013-10-12: Впечатления с AgileKitchen
Материал из CustisWiki
|
|
(не показаны 2 промежуточные версии 2 участников) | Строка 1: |
Строка 1: |
− | Серия осенних конференций началась с [http://agilerussia.timepad.ru/event/83430/ AgileKitchen]. В конце месяца будет [http://2013.secr.ru SECR] с Иваром Якобсоном, потом - [http://sqadays.com SQAdays] во Львове с отдельным днем европейских докладчиков, а в начале декабря - [http://spmconf.ru/ SPMconf] в Казани. Это - те, на которых я планирую быть, чтобы услышать, почувствовать новые тренды отрасли, узнать новые практики. И удачное начало этому было положено на AgileKitchen в эту пятницу, на территории Лаборатории Касперского. | + | Серия осенних конференций началась с [http://agilerussia.timepad.ru/event/83430/ AgileKitchen]. В конце месяца будет [http://2013.secr.ru SECR] с Иваром Якобсоном, потом — [http://sqadays.com SQAdays] во Львове с отдельным днем европейских докладчиков, а в начале декабря — [http://spmconf.ru/ SPMconf] в Казани. Это — те, на которых я планирую быть, чтобы услышать, почувствовать новые тренды отрасли, узнать новые практики. И удачное начало этому было положено на AgileKitchen в эту пятницу, на территории Лаборатории Касперского. |
| | | |
− | Несмотря на название и позиционирование как обмен мнениями "на кухне", это было достаточно серьезное мероприятие. И по числу участников - думаю, было около сотни, хотя могу ошибаться, которые сидели в большом зале, объединенном из трех переговорных с тремя большими экранами, и по уровню организации. И, главное - по характеру выступлений. На AgileKitchen выносятся темы, которые на острие развития, не успели обрасти серьезными теориями и практиками, но которые пробуют изучать и применять. И люди обмениваются опытом. А еще - там делятся практическим опытом решения задач, которые почему-то не становятся менее актуальными, несмотря на, казалось бы, давно известные подходы к решению. Их решают в конкретных условиях, и каждое новое решение имеет свои особенности, дает какой-то новый опыт, который тоже интересно обсудить. | + | Несмотря на название и позиционирование как обмен мнениями «на кухне», это было достаточно серьезное мероприятие. И по числу участников — думаю, было около сотни, хотя могу ошибаться, — которые сидели в большом зале, объединенном из трех переговорных с тремя большими экранами, и по уровню организации. И, главное — по характеру выступлений. На AgileKitchen выносятся темы, которые сейчас на острие развития, не успели обрасти серьезными теориями и практиками, но которые пробуют изучать и применять. И люди обмениваются опытом. А еще — там делятся практическим опытом решения задач, которые почему-то не становятся менее актуальными, несмотря на, казалось бы, давно известные подходы к решению. Их решают в конкретных условиях, и каждое новое решение имеет свои особенности, дает какой-то новый опыт, который тоже интересно обсудить. |
| | | |
− | Собственно, обсуждение практического опыта - самая важная составляющая мероприятия. И его было много - в перерывах между докладами, на OpenSpace, после конференции. | + | Собственно, обсуждение практического опыта — самая важная составляющая мероприятия. И его было много: в перерывах между докладами, на OpenSpace, после конференции. |
| + | |
| + | '''UPD. [https://www.evernote.com/shard/s9/sh/497612c3-ad1d-4dd9-8502-9c203f9f691f/47ce75f2cdd5143da419f50c1d64f0b9 Материалы конференции]''' |
| | | |
| = Мотивация и коммуникации = | | = Мотивация и коммуникации = |
Строка 9: |
Строка 11: |
| Обзор выступлений я на этот раз начну с темы '''мотивации и коммуникации''', которая была темой сразу нескольких докладов. | | Обзор выступлений я на этот раз начну с темы '''мотивации и коммуникации''', которая была темой сразу нескольких докладов. |
| | | |
− | == Motivation 3.0 - что вы должны знать для работы с командой - Алексей Пименов == | + | == Motivation 3.0: что вы должны знать для работы с командой (Алексей Пименов) == |
| | | |
− | Алексей Пименов работает в ФИНАМ. Он рассказывал об эволюции теории мотивации и исследованиях в этой области. О том, что правильная мотивация для творческих задач, которыми занимаются ИТ-шники - возникает когда ты находишься "в потоке". А это означает, что подходы, основанные на различных KPI и метриках - не уместны. Что особенно интересно - он сумел рассказать это не только нам, программистам, которые "в теме". Он сумел убедить в этом не-ИТ-менеджеров у себя в компании. | + | Алексей Пименов работает в ФИНАМ. Он рассказывал об эволюции теории мотивации и исследованиях в этой области. О том, что правильная мотивация для творческих задач, которыми занимаются ИТ-шники, возникает, когда ты находишься «в потоке». А это означает, что подходы, основанные на различных KPI и метриках, — неуместны. Что особенно интересно — он сумел рассказать это не только нам, программистам, которые «в теме». Он сумел убедить в этом не-ИТ-менеджеров у себя в компании. |
| | | |
| Версии мотивации в изложении Алексея. | | Версии мотивации в изложении Алексея. |
| | | |
− | '''Мотивация 1.0''' - нами управляют потребности. Пирамида Маслоу. Понятно, что для потребностей нужна система сдержек и противовесов, на случай противоречащих потребностей разных людей. И это ведет к следующей ступени. | + | '''Мотивация 1.0''' — нами управляют потребности. Пирамида Маслоу. Понятно, что для потребностей нужна система сдержек и противовесов, на случай противоречащих потребностей разных людей. И это ведет к следующей ступени. |
| | | |
− | '''Мотивация 2.0''' - Мы стремимся к удовольствиям избегая наказаний. А удовольствия и наказания отмеряются по Тейлору, в научной организации труда. Что приводит к KPI и методу Кнута и Пряника. | + | '''Мотивация 2.0''' — мы стремимся к удовольствиям, избегая наказаний. А удовольствия и наказания отмеряются, по Тейлору, в научной организации труда. Что приводит к KPI и методу Кнута и Пряника. |
| | | |
− | У этой системы есть 7 фатальных изъянов. | + | У этой системы есть 7 фатальных изъянов: |
− | * Могут гасить внутреннюю мотивацию | + | * могут гасить внутреннюю мотивацию; |
− | * Могут снижать эффективность | + | * могут снижать эффективность; |
− | * Могут подавлять творчество | + | * могут подавлять творчество; |
− | * Вытесняют хорошее поведение | + | * вытесняют хорошее поведение; |
− | * Поощряют мошенничество, поиск легких путей, неэтичное поведение. Игра SLAka - выдержать SLA у себя и скинуть так, чтобы соседи не выполнили | + | * поощряют мошенничество, поиск легких путей, неэтичное поведение. Игра SLAka — выдержать SLA у себя и скинуть так, чтобы соседи не выполнили; |
− | * Могут вызывать привыкание | + | * могут вызывать привыкание; |
− | * Могут развивать косность мышления | + | * могут развивать косность мышления. |
| | | |
− | Более того, довольно давно проводились эксперименты, показывающие, что потребности и наказания вовсе не являются единственной и даже самой сильной движущей силой интеллектуальной деятельности. И не только у человека, но и у обезьян эксперименты Гарри Харлоу в 1949 показали, что обезьяны разгадывают головоломки "просто так", и добавление к этому элемента вознаграждения (изюм) увеличивает результат (ускоряет разгадывание) незначительно. | + | Более того, довольно давно проводились эксперименты, показывающие, что потребности и наказания вовсе не являются единственной и даже самой сильной движущей силой интеллектуальной деятельности. И не только у человека, но и у обезьян. Эксперименты Гарри Харлоу в 1949 показали, что обезьяны разгадывают головоломки «просто так», и добавление к этому элемента вознаграждения (изюм) увеличивает результат (ускоряет разгадывание) незначительно. |
| | | |
− | Дуглас МакГрегор в 1960 году в Human Side of Enterprise ввел понятие людей двух видов: X-person, которым нужен менеджер и Y-person, которые увлечены сами. | + | Дуглас МакГрегор в 1960 году в Human Side of Enterprise ввел понятие людей двух видов: X-person, которым нужен менеджер, и Y-person, которые увлечены сами. |
| | | |
− | А в 1969 Эдвард Леси на экспериментах с людьми, аналогичных опыту Харлоу показал, что добавление материальной мотивации убивает творческий процесс, который без нее - развивается. | + | А в 1969 Эдвард Леси на экспериментах с людьми, аналогичных опыту Харлоу показал, что добавление материальной мотивации убивает творческий процесс, который без нее — развивается. |
| | | |
− | Так возникает '''Мотивация 2.1''' - интегрируем в 2.0 МакГрегор. | + | Так возникает '''Мотивация 2.1''' — интегрируем в 2.0 МакГрегор. |
− | * Рутина Без разнообразия - Деньги. Признать, что рутинная, разрешить выбрать способ для компенсации. | + | * Рутина без Разнообразия — Деньги. Признать, что рутинная, разрешить выбрать способ для компенсации. |
− | * Рутина с Разнообразием или НеРутина - обеспечиваем условия, и работаем на самореализацию. Признание заслуг и прочее. Командное взаимодействие. А деньги всегда даем неожиданно - иначе он будет пользоваться именно этим. | + | * Рутина с Разнообразием или НеРутина — обеспечиваем условия и работаем на самореализацию. Признание заслуг и прочее. Командное взаимодействие. А деньги всегда даем неожиданно — иначе он будет пользоваться именно этим. |
| | | |
− | Возникает вопрос - а что значит "обеспечить условия работы"? Отчасти ответ дает двухфакторная теория мотивации Герцберга - надо обеспечить гигиенические факторы. Но этого недостаточно. | + | Возникает вопрос — а что значит «обеспечить условия работы»? Отчасти ответ дает двухфакторная теория мотивации Герцберга — надо обеспечить гигиенические факторы. Но этого недостаточно. |
| | | |
− | В 1990 появилась работа Михай Чиксентмихайи. Мысль, что "мы проживаем жизнь неправильно". У человека есть состояние потока, в котором индивид может направлять внимание на свои цели, потому что не надо бороться с отвлечением внимания и угрозам. Состояние потока - единение с деятельностью и ситуацией. И так возникла '''Мотивация 3.0''' - мы стимулируем участие, естественное желание работать путем переживания потока. | + | В 1990 появилась работа Михай Чиксентмихайи. Мысль, что «мы проживаем жизнь неправильно». У человека есть состояние потока, в котором индивид может направлять внимание на свои цели, потому что не надо бороться с отвлечением внимания и угрозам. Состояние потока — единение с деятельностью и ситуацией. И так возникла '''Мотивация 3.0''' — мы стимулируем участие, естественное желание работать путем переживания потока. |
| | | |
− | Правда, готовых рецептов тут нет. Речь идет об индивидуальной работе. Потому что состояние потока возможно, когда человек увлечен, а еще - когда он находится в допустимом коридоре по осям Требования - Умения. Потому что когда Требования > Умений = Тревога, а Умения > Требований = Скука. | + | Правда, готовых рецептов тут нет. Речь идет об индивидуальной работе. Потому что состояние потока возможно, когда человек увлечен, а еще — когда он находится в допустимом коридоре по осям Требования — Умения. Потому что, когда Требования > Умений = Тревога, а Умения > Требований = Скука. |
| | | |
− | Но есть правила, что помогает, и что мешает. Помогает. | + | Но есть правила того, что помогает, и что мешает. Помогает: |
− | * Ясность в отношениях - знаете, что хотят | + | * ясность в отношениях — знаете, что хотят; |
− | * Интерес руководителя, что думает и чувствует подчиненный, а не только к прогрессу задачи | + | * интерес руководителя, что думает и чувствует подчиненный, а не только к прогрессу задачи; |
− | * Предоставление возможности выбора и принятие ответственности за него | + | * предоставление возможности выбора и принятие ответственности за него |
− | * Чувство общности (поддержка, ценности) | + | * чувство общности (поддержка, ценности); |
− | * НЛП-шное якорение. Один раз войдя в состояние - повесить якорь и научиться входить туда же. Правда он не умеет, но про инструмент - знает | + | * НЛП-шное якорение. Один раз войдя в состояние, повесить якорь и научиться входить туда же. Правда он не умеет, но про инструмент — знает |
− | Agile содержит много практик, которые работают именно в этих направлениях - обратная связь, ценностная модель, совместная деятельность. | + | Agile содержит много практик, которые работают именно в этих направлениях: обратная связь, ценностная модель, совместная деятельность. |
| | | |
− | Что мешает. | + | Что мешает: |
− | * Психическая не предрасположенность - шизофреники | + | * Психическая не предрасположенность — шизофреники. |
− | * Социально. Отсутствие правил - неясно, что можно; Неясно, что нужно. Состояние отчуждения | + | * Социальный фактор. Отсутствие правил — неясно, что можно; неясно, что нужно. Состояние отчуждения. |
− | * Личные патологии. Невозможность концентрироваться (может и врожденная). Чрезмерная сосредоточенность на себе (эгоцентризм, личная выгода). | + | * Личные патологии. Невозможность концентрироваться (может, и врожденная). Чрезмерная сосредоточенность на себе (эгоцентризм, личная выгода). |
− | И если сопоставить эти списки с KPI и подобными подходами Мотивации 2.1, то ясно, что они - скорее мешают, чем помогают. | + | И если сопоставить эти списки с KPI и подобными подходами Мотивации 2.1, то ясно, что они — скорее мешают, чем помогают. |
| | | |
− | На этом - все. Но тема - интересная. От себя хочу добавить, что есть известная книга Мифы Мотивации Шпренгера, в которой он показывает, как мотивация 2.0 (бонусы и прочие изобретения) приводят в тупик в долгосрочной перспективе даже для продавцов. | + | На этом — все. Но тема интересная. От себя хочу добавить, что есть известная книга «Мифы мотивации» Шпренгера, в которой он показывает, как мотивация 2.0 (бонусы и прочие изобретения) приводят в тупик в долгосрочной перспективе даже для продавцов. |
| | | |
− | == Игрофицированный менеджмент - Коробцев Максим, GameTrek == | + | == Игрофицированный менеджмент (Коробцев Максим, GameTrek) == |
| | | |
− | Максима я слышал на AgileDays, где тоже делал доклад про gamification. По-русски это называли как "геймификация", однако слово имеет всякие неправильные оттенки, поэтому теперь Максим предпочитает полную русификацию термина. | + | Максима я слышал на AgileDays, где тоже делал доклад про Gamification. По-русски это называли как «геймификация», однако слово имеет всякие неправильные оттенки, поэтому теперь Максим предпочитает полную русификацию термина. |
| | | |
− | Начал он с того, что понимания многими игрофикация как раздача ленточек, вымпелов и других наград - есть, в целом, профанация идеи. Для нее даже специальный термин есть - бейджификация. А профанация это потому, что быстро сваливается в формльаность, нет азарта и состояния потока. | + | Начал он с того, что понимание многими игрофикации как раздачи ленточек, вымпелов и других наград — есть, в целом, профанация идеи. Для нее даже специальный термин есть — бейджификация. А профанация это потому, что быстро сваливается в формальность, нет азарта и состояния потока. |
| | | |
− | Игрофикация - игровая значимость реальных рабочих активностей. И она помогает работе за счет увдечения людей, а еще - за счет того, что доносит через игровую форму до людей правильные приоритеты. потому что нет проблемы нехватки времени, есть только проблема неверной расстановки приоритетов. | + | Игрофикация — игровая значимость реальных рабочих активностей. И она помогает работе за счет увлечения людей, а еще - за счет того, что доносит в игровой форме до людей правильные приоритеты. Потому что нет проблемы нехватки времени, есть только проблема неверной расстановки приоритетов. |
| | | |
| Максим привел три конкретных игры, которые были разработаны и применяются, или планируются к применению для решения конкретных производственных задач. | | Максим привел три конкретных игры, которые были разработаны и применяются, или планируются к применению для решения конкретных производственных задач. |
| | | |
− | Первая - track2win. Метафора автомобильной гонки, 12 этапов по месяцам. Ты едешь на машине, плюс собираешь награды. При этом машинки двигаются основной работой, это можно завязывать на багтрекер или другие рабочие показатели. А вот награды связаны с дополнительными активностями, поощряемыми компаниями, например, с выступлениями на конференциях и публикациями. Дальше вопрос тонкой настройки и балансировки. включая нескольких измерений лидерства. Игра реально используется, говорит, что отрицательных эффектов - не замечено. Есть люди и ситуации, когда которых игра не действует, но при этом производительность соответствует тому, что было без игры, а не ниже. Пока игра - чистый PvP, то есть конкуренция, они думают, как добавить другие элементы, чтобы была командная работа. А еще - готовят версию с ролями, чтобы разработчики могли соревноваться с тестировщиками, например. | + | Первая — track2win. Метафора автомобильной гонки, 12 этапов по месяцам. Ты едешь на машине, плюс собираешь награды. При этом машинки двигаются основной работой, это можно завязывать на багтрекер или другие рабочие показатели. А вот награды связаны с дополнительными активностями, поощряемыми компаниями, например, с выступлениями на конференциях и публикациями. Дальше вопрос тонкой настройки и балансировки. Включая нескольких измерений лидерства. Игра реально используется, по словам докладчика, отрицательных эффектов — не замечено. Есть люди и ситуации, когда игра не действует, но при этом производительность соответствует тому, что было без игры, а не ниже. Пока игра — чистый PvP, то есть конкуренция, они думают, как добавить другие элементы, чтобы была командная работа. А еще — готовят версию с ролями, чтобы разработчики могли соревноваться с тестировщиками, например. |
| | | |
− | Вторая игра "Коробки", ее запускают для Одноклассников. Цель - устранить технический долг, обеспечить исправление мелких ошибок, за которые берутся неохотно. Идея - каждый месяц вываливается "ящик Пандоры" - коробка ошибок для устранения за заданное время "разбора коробки". Ошибки - персонифицированы, ты помогаешь конкретному пользователю с его проблемой. А еще - нарабатываешь скилы. При этом техника прохождения может быть различной, можно соревноваться в количестве - тогда люди будут брать то, что хорошо умеют, а можно - через "чек-пойнты", разнородные ошибки. если хотим прокачивать кроссфункциональность. | + | Вторая игра «Коробки», ее запускают для Одноклассников. Цель — устранить технический долг, обеспечить исправление мелких ошибок, за которые берутся неохотно. Идея — каждый месяц вываливается «ящик Пандоры» — коробка ошибок для устранения за заданное время «разбора коробки». Ошибки — персонифицированные, ты помогаешь конкретному пользователю с его проблемой. А еще — нарабатываешь скилы. При этом техника прохождения может быть различной, можно соревноваться в количестве — тогда люди будут брать то, что хорошо умеют, а можно — через «чек-пойнты», разнородные ошибки, если хотим прокачивать кроссфункциональность. |
| | | |
− | Еще есть игра NASA против космической угрозы. Когда всякая проблема визуализируется как комета на землю, а дальше рабочая группа должна образоваться и с ней справляться, и это - видно. | + | Еще есть игра «NASA против космической угрозы». Когда всякая проблема визуализируется как комета, приближающаяся к Земле, а дальше рабочая группа должна образоваться и с ней справляться, и это — видно. |
| | | |
− | Как видно, большинство этих техник - они нацелены на решение рутинных или вспомогательных задач, наряду с основной интересной работой. | + | Как видно, большинство этих техник — они нацелены на решение рутинных или вспомогательных задач, наряду с основной интересной работой. |
| | | |
− | И принципиально: игра - '''не''' обязательно. Но люди - вовлекаются по классической кривой вовлечения. | + | И принципиально: игра — '''не''' обязательно. Но люди — вовлекаются по классической кривой вовлечения. |
| | | |
− | == Right Team: Баланс и Резонанс взаимодействия - Майк Рыжиков == | + | == Right Team: Баланс и Резонанс взаимодействия (Майк Рыжиков) == |
| | | |
| Майк рассказывал о коммуникациях в командах, построении эффективного командного взаимодействия. | | Майк рассказывал о коммуникациях в командах, построении эффективного командного взаимодействия. |
| | | |
− | В целом в фундаменте командного взаимодействия лежат три вещи | + | В целом в фундаменте командного взаимодействия лежат три вещи: |
− | * Лидерство | + | * Лидерство; |
− | * Единая Система ценностей | + | * Единая Система ценностей; |
− | * Единый профессиональный контекст | + | * Единый профессиональный контекст. |
− | Однако, в докладе о них подробно не говорили. Просто о них - надо помнить, говоря о команде. А предметом выступление было выстраивание взаимодействия. | + | Однако, в докладе о них подробно не говорили. Просто о них надо помнить, говоря о команде. А предметом выступление было выстраивание взаимодействия. |
| | | |
| Проблема: результаты взаимодействия часто носят непредсказуемый характер (позитивный или негативный). | | Проблема: результаты взаимодействия часто носят непредсказуемый характер (позитивный или негативный). |
Строка 95: |
Строка 97: |
| | | |
| Виды взаимодействия. | | Виды взаимодействия. |
− | * Balance 1+1=2. Сильные стороны дополняют друг друга. Надо знать сильные и слабые стороны свои и других. Но! часто есть недооценка или переоценка сторон и с этим надо работать. Например, тренер, оценивающий. Зона применения - исполнение в рамках понятной концепции. | + | * Balance 1+1=2. Сильные стороны дополняют друг друга. Надо знать сильные и слабые стороны свои и других. Но! часто есть недооценка или переоценка сторон и с этим надо работать. Например, тренер, оценивающий. Зона применения — исполнение в рамках понятной концепции. |
− | * Resonance 1+1 > 2. Резонирующее - совпадение частот. Гармонизация целей, гармонизация контекста, очередность (у солистов резонанса не будет). Зона применения - генерация идей, надо раскачивать друг друга. | + | * Resonance 1+1 > 2. Резонирующее — совпадение частот. Гармонизация целей, гармонизация контекста, очередность (у солистов резонанса не будет). Зона применения — генерация идей, надо раскачивать друг друга. |
| * Anticooperation 1+1 < 2. Его, понятно, надо устранять. | | * Anticooperation 1+1 < 2. Его, понятно, надо устранять. |
| | | |
− | Организованное взаимодействие | + | Организованное взаимодействие: |
− | * Создание точек взаимодействия | + | * Создание точек взаимодействия; |
− | * Самоанализ и взаимоанализ | + | * Самоанализ и взаимоанализ; |
− | * Тренер и Тренировочный процесс | + | * Тренер и Тренировочный процесс; |
− | * Фасилитация Ритуалы | + | * Фасилитация и Ритуалы; |
− | * Ретроспективы для взаимодействия | + | * Ретроспективы для взаимодействия; |
| * Работа в парах, Коллективное принятие решений. | | * Работа в парах, Коллективное принятие решений. |
− | В целом мысли понятные и важные, но по кейсам уровень - не слишком высокий. Потому что у них стабильная многолетняя сложившаяся команда с двумя лидерами - организационным и техническим. Это - самая простая конструкция. Хотя, нельзя сказать, что раз она простая - ее просто построить. Далеко не всем это удается, и удачный опыт - ценный. А сложившаяся она - сейчас, они выходят на Performing. На этапе Storming было непросто. А на OpenSpace Майк делился опытом решения проблем. | + | В целом, мысли понятные и важные, но по кейсам уровень — не слишком высокий. Потому что у них стабильная многолетняя сложившаяся команда с двумя лидерами — организационным и техническим. Это самая простая конструкция. Хотя, нельзя сказать, что раз она простая — ее просто построить. Далеко не всем это удается, и удачный опыт — ценный. А сложившаяся она — сейчас, они выходят на Performing. На этапе Storming было непросто. А на OpenSpace Майк делился опытом решения проблем. |
| | | |
| = Методы: SEMAT, А3 и теория ограничений = | | = Методы: SEMAT, А3 и теория ограничений = |
| | | |
− | == OMG SEMAT — единая теория программной инженерии - Юрий Куприянов == | + | == OMG SEMAT — единая теория программной инженерии (Юрий Куприянов) == |
| | | |
− | Это доклад о новом продукте SEMAT (Software engineering method and theory) - Essence of Software Engineering: Kernel and Language. Я о нем знаю из разных источников, поэтому в описании доклада услышанное на докладе и узнанное ранее будет перемежаться. А еще - после доклада было много обсуждений, и часть мыслей - оттуда. | + | Это доклад о новом продукте SEMAT (Software Engineering Method and Theory) — Essence of Software Engineering: Kernel and Language. Я о нем знаю из разных источников, поэтому указанное в описании доклада, услышанное на докладе и узнанное ранее будет перемежаться. А еще — после доклада было много обсуждений, и часть мыслей оттуда. |
| | | |
− | Основная мысль авторов - проанализировать имеющееся описание разнообразных процессов и методов разработки софта на полном жизненном цикле с тем, чтобы создать язык для их формального описания, и - описать на этом языке имеющиеся методы и практики. И как идеальный результат - вы получаете возможность их сравнить, это во-первых, а, во-вторых - конструировать на их основе собственные процессы и методы. При этом за счет формального описания вы сможете достаточно быстро описывать новым сотрудникам и другими интересантам, чем ваши процессы отличаются от стандартных, а при проведении изменений - чем целевое состояние будет отличаться от того, чем сейчас. И, наконец, при конструировании можно будет использовать имеющиеся практики из библиотеки, то есть пользоваться опытом индустрии, а не конструировать с нуля. | + | Основная мысль авторов — проанализировать имеющееся описание разнообразных процессов и методов разработки софта на полном жизненном цикле с тем, чтобы создать язык для их формального описания, и — описать на этом языке имеющиеся методы и практики. И как идеальный результат — вы получаете возможность их сравнить, это во-первых, а во-вторых, — конструировать на их основе собственные процессы и методы. При этом за счет формального описания вы сможете достаточно быстро описывать новым сотрудникам и другими интересантам, чем ваши процессы отличаются от стандартных, а при проведении изменений — чем целевое состояние будет отличаться от того, что есть сейчас. И, наконец, при конструировании можно будет использовать имеющиеся практики из библиотеки, то есть пользоваться опытом индустрии, а не конструировать с нуля. |
| | | |
− | Пока все подобные описания выполнялись просто текстом, наличие формального языка - упрощает ситуацию. Тем более, что учитывая уроки UML в язык сразу заложена графическая нотация для эффективного представления. А учитывая развитие Agile-методологий, которые достигли успеха во многом благодаря простоте представления, отличавшей их от тяжелых описаний традиционных методологий, авторы предприняли специальные усилия для упрощения методологии, пусть пожертвовав выразительными средствами и сложностями моделей. | + | Пока все подобные описания выполнялись просто текстом, наличие формального языка упрощает ситуацию. Тем более, что, учитывая уроки UML, в язык сразу заложена графическая нотация для эффективного представления. А учитывая развитие Agile-методологий, которые достигли успеха во многом благодаря простоте представления, отличавшей их от тяжелых описаний традиционных методологий, авторы предприняли специальные усилия для упрощения методологии, пусть пожертвовав выразительными средствами и сложностями моделей. |
| | | |
− | Как идея все это звучит хорошо. Но вызывает опасения, что опять получится нечто громоздкое и слабоприменимое. Глава рабочей группы, которая все это создала - Ивар Якобсон, один из создателей UML и RUP. И с этим тоже связаны опасения. UML в простых проявлениях - используется много, а вот как полноценный язык - не очень. А на смену RUP как раз и пришел agile. Но, смотря на результат сейчас - он вдохновляет на использование. Он очень свежий, появился только в этом году, поэтому о полноценном использовании пока говорить рано. Но его пробуют применить в своих проектах. А еще - в обучении, и там он оказался весьма эффективен, потому что позволяет связать все аспекты деятельности в единое целое, и дает пути, по которым можно пробовать идти без практического опыта ведения проектов, наполняя содержанием своего модельного или реального проекта. | + | Как идея все это звучит хорошо. Но вызывает опасения, что опять получится нечто громоздкое и слабоприменимое. Глава рабочей группы, которая все это создала, — Ивар Якобсон — один из создателей UML и RUP. И с этим тоже связаны опасения. UML в простых проявлениях — используется много, а вот как полноценный язык — не очень. А на смену RUP как раз и пришел Agile. Но, глядя на результат сейчас, можно сказать — он вдохновляет на использование. Он очень свежий, появился только в этом году, поэтому о полноценном использовании пока говорить рано. Но его пробуют применить в своих проектах. А еще — в обучении, и там он оказался весьма эффективен, потому что позволяет связать все аспекты деятельности в единое целое и дает пути, по которым можно пробовать идти без практического опыта ведения проектов, наполняя содержанием своего модельного или реального проекта. |
| | | |
− | В докладе был краткий обзор Essence и источников, а практический опыт как раз больше касался знакомства, собственных попыток применить и обучения. | + | В докладе был краткий обзор Essence и источников, а практический опыт как раз больше касался знакомства, собственных попыток применения и обучения. |
| | | |
− | Обзор я совсем кратко повторю. Для начала - терминология. Она во многом оригинальная, и это авторами сделано сознательно. Оригинальная она там, где использование существующих терминов вызывало бы нежелательные коннотации, связанные с применением термина в рамках существующих методологий и процессов и привела бы к потере существенных оттенков смысла. Там, где этого нет - брали существующий термин, поэтому, например, customer и stakeholder - остались. Зато появились Alpha и Endeavor. | + | Обзор я совсем кратко повторю. Для начала — терминология. Она во многом оригинальная, и это авторами сделано сознательно. Оригинальная она там, где использование существующих терминов вызывало бы нежелательные коннотации, связанные с применением термина в рамках существующих методологий и процессов и привела бы к потере существенных оттенков смысла. Там, где этого нет, — брали существующий термин, поэтому, например, Customer и Stakeholder — остались. Зато появились Alpha и Endeavor. |
| | | |
| Все описание мира разделено на три больших части: | | Все описание мира разделено на три больших части: |
− | * Предметы - это альфы и их экземпляры, рабочие продукты. | + | * Предметы - это альфы и их экземпляры, рабочие продукты; |
− | * Деятельность, activity space. | + | * Деятельность, Activity Space; |
− | * B Competence. | + | * B Competence. |
| | | |
− | Альфа, для которой придумана расшифровка Abstract Level of Progress Health Attribute - это очень абстрактное понятие. Это нечто, что имеет состояния, по изменению которого мы можем судить о продвижении (progress) или здоровье (health) нашей деятельности. И это - идеальный предмет, тип, у которого в реальности возникают экземпляры (instance) - это рабочие продукты (Work Product). Альфы имеют последовательность состояний, с состоянием связан набор признаков (check list), которые должны быть зафиксированы для того, чтобы альфа его получила. И связана разнообразными ассоциациями с другими альфами. Деятельность - совершается над экземпляром альфы - рабочим продуктом - или несколькими, и что-то в них изменяет, в результате они могут изменить свои состояния. А компетенции - это способность определенные действия производить. Это если совсем кратко на абстрактном уровне. | + | Альфа, для которой придумана расшифровка Abstract Level of Progress Health Attribute — это очень абстрактное понятие. Это нечто, что имеет состояния, по изменению которого мы можем судить о продвижении (Progress) или здоровье (Health) нашей деятельности. И это — идеальный предмет, тип, у которого в реальности возникают экземпляры (Instance) — это рабочие продукты (Work Product). Альфы имеют последовательность состояний, с состоянием связан набор признаков (Check List), которые должны быть зафиксированы для того, чтобы альфа его получила. И связана разнообразными ассоциациями с другими альфами. Деятельность — совершается над экземпляром альфы — рабочим продуктом — или несколькими, и что-то в них изменяет, в результате они могут изменить свои состояния. А компетенции — это способность определенные действия производить. Это если совсем кратко на абстрактном уровне. |
| | | |
− | На конкретном уровне программной инженерии все поле альф делится на три области: | + | На конкретном уровне программной инженерии все поле альф делится на три области. |
− | * Customer - это окружающий мир, заказчики и интересанты. | + | * Customer — это окружающий мир, заказчики и интересанты. |
− | * Solution - это решение, предмет-результат деятельности, программная система. | + | * Solution — это решение, предмет-результат деятельности, программная система. |
− | * Endeavor - это сама деятельность. В этом месте ранее употребляли слово "Проект", однако Essence описывает деятельность на полном жизненном цикле, а на этапе эксплуатации проекты занимают весьма ограниченное место. Говорят, в рабочей группе SEMAT есть представитель, занимающийся эксплуатацией и она тщательно вымарывает слово "проект" по площади. | + | * Endeavor — это сама деятельность. В этом месте ранее употребляли слово «Проект», однако Essence описывает деятельность на полном жизненном цикле, а на этапе эксплуатации проекты занимают весьма ограниченное место. Говорят, в рабочей группе SEMAT есть представитель, занимающийся эксплуатацией, и она тщательно вымарывает слово «проект»по площади. |
| | | |
− | И Essence говорит, что для описания создания софта вам потребуется в этих областях минимально 7 (семь) альф. | + | И Essence говорит, что для описания создания софта вам потребуется в этих областях минимально 7 (семь) альф: |
− | * Возможности (Oportunity) и Стейкхолдеры в окружающем мире | + | * Возможности (Oportunity) и Стейкхолдеры в окружающем мире; |
− | * Требования и Програмная система (Software System) в области решения | + | * Требования и Програмная система (Software System) в области решения; |
− | * Работы (Work), Технологии работы (way-of-work) и Команды в Endeavor. | + | * Работы (Work), Технологии работы (Way-of-Work) и Команды в Endeavor. |
− | Больше - можно. И можно описывать подтипы. Но вот меньше - нельзя. | + | Больше — можно. И можно описывать подтипы. Но вот меньше — нельзя. |
| | | |
− | Дальше для всех основных альф описаны состояния - на полном жизненном цикле. Например, для стекйкхолдеров это Выявлены - Представлены - Вовлечены - В согласии - Удовлетворены развертыванием - Удовлетворены работой системы. Обратите внимание на два последних - это - тоже состояния стейкхолдеров. И, естественно, помимо прямого пути возможен откат по графу. Состояние фиксируется для каждого отдельного стейкхолдера или для каких-то групп персонификаций, для всех вместе - как вы построили свое описание. | + | Дальше для всех основных альф описаны состояния — на полном жизненном цикле. Например, для стекйкхолдеров это Выявлены - Представлены - Вовлечены - В согласии - Удовлетворены развертыванием - Удовлетворены работой системы. Обратите внимание на два последних: это тоже состояния стейкхолдеров. И, естественно, помимо прямого пути возможен откат по графу. Состояние фиксируется для каждого отдельного стейкхолдера или для каких-то групп персонификаций, для всех вместе — как вы построили свое описание. |
| | | |
− | И это образует Kernel - ядро программной инженерии. Включая карточки чек-листов для состояний. А дальше есть библиотека - описания имеющихся практик и методов. На языке и в понятиях ядра описаны распространенные методы Scrum, User Story и Multi-phase Waterfall, показано, как выстраиваются комбинации, описаны расширения базовых альф для бизнес-анализа, разработки и управления задачами, и так далее. Например, в расширении для бизнес-анализа наряду с Возможностями и Требованиями появляются Нужды (Need), которые становятся механизмом для движения Возможностей по состояниям. Авторы утверждают, что все известные методы создания и сопровождения программных систем являются комбинацией из менее чем 250 практик. Число большое, но обозримое. И все их можно описать в предложенном формализме и, более того, они это сделают. В обсуждении доклада неоднократно всплывали методы ITIL, их формализации пока вроде не видели (что не означает, что их нет). | + | И это образует Kernel — ядро программной инженерии. Включая карточки чек-листов для состояний. А дальше есть библиотека — описания имеющихся практик и методов. На языке и в понятиях ядра описаны распространенные методы Scrum, User Story и Multi-Phase Waterfall, показано, как выстраиваются комбинации, описаны расширения базовых альф для бизнес-анализа, разработки и управления задачами, и так далее. Например, в расширении для бизнес-анализа наряду с Возможностями и Требованиями появляются Нужды (Need), которые становятся механизмом для движения Возможностей по состояниям. Авторы утверждают, что все известные методы создания и сопровождения программных систем являются комбинацией из менее чем 250 практик. Число большое, но обозримое. И все их можно описать в предложенном формализме и, более того, они это сделают. В обсуждении доклада неоднократно всплывали методы ITIL, их формализации пока вроде не видели (что не означает, что их нет). |
| | | |
− | Кроме [http://www.omg.org/spec/Essence/1.0/Beta1/PDF/ текста стандарта], который достаточно сух, есть книга Ивара Essence, которая более нацелена на практическое применение. Там есть практические кейсы, при чем в вариантах, пригодных как организации обучения с передачей сути, так и для постановки формального процесса, понимаемого через деятельность. При масштабировании надо и то и другое - обучение через деятельность - гораздо более быстрое, и понимание сути не является необходимым для всех. | + | Кроме [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.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 слайдам Юры], которые он уже выложил. А в обсуждении, откуда начать знакомиться, возникла идея, что тут неплохо сработает обучение бросанием в воду. Берешь один из последних постов Левенчука, например, [http://ailev.livejournal.com/1083339.html этот] и копаешь по ссылкам в прошлое и на стандарты, пока не станет понятным. А на SECR можно будет не только услышать Ивара, но и пообщаться с ним [http://2013.secr.ru/lang/ru/program/open-discussion-corner в дискуссионном уголке]. |
| | | |
− | == Опыт применения A3 в компании Skype - Алексей Ильичев == | + | == Опыт применения A3 в компании Skype (Алексей Ильичев) == |
| | | |
− | A3-анализ — это подход к решению стратегических проблем, применявшийся в Тойоте. Суть его в том, что под одну проблему заводится лист формата А3, на котором коротко изложена суть проблемы, анализ и контр-меры. Алексей рассказывал о том, как в компании Skype они пробуют применять этот метод на трех практических кейсах. | + | A3-анализ — это подход к решению стратегических проблем, применявшийся в «Тойоте». Суть его в том, что под одну проблему заводится лист формата А3, на котором коротко изложена суть проблемы, анализ и контр-меры. Алексей рассказывал о том, как в компании Skype они пробуют применять этот метод на трех практических кейсах. |
| | | |
− | Кейсы: проблемы с дизайнерами, из-за запаздывания работы которых возникали сложности с релизами, проблема с разрешением на использование open source библиотек и организация работы с QuickBuild. | + | Кейсы: проблемы с дизайнерами, из-за запаздывания работы которых возникали сложности с релизами, проблема с разрешением на использование Opensource-библиотек и организация работы с QuickBuild. |
| | | |
− | Сразу скажу, что во всех случаях проблемы решались просто от их осознания и обсуждения. В случае с opensource вообще оказалось, что ответственные лица готовят документ, и через полгода будет счастье. Только ситуация была такова, что полгода ждать было нельзя и нужно было временное решение, и проведенный анализ как раз обосновывал остроту ситуации. Подробно описывать кейсы я не буду, интересующиеся могут посмотреть запись, когда она появится. | + | Сразу скажу, что во всех случаях проблемы решались просто от их осознания и обсуждения. В случае с Opensource вообще оказалось, что ответственные лица готовят документ, и через полгода будет счастье. Только ситуация была такова, что полгода ждать было нельзя и нужно было временное решение, и проведенный анализ как раз обосновывал остроту ситуации. Подробно описывать кейсы я не буду, интересующиеся могут посмотреть запись, когда она появится. |
| | | |
− | Практически формат использовался как '''решение проблемы снизу''', в любом месте, где она возникает. Роль формата А3 в том, что при этом любой сотрудник, заинтересованный в проблеме, но не имеющий навыка решения, получает форму, следуя которой он может продвигаться, обсуждая проблему на всех уровнях и получая доказательную базу для обсуждения с руководством. Я знаю, что этого - часто не хватает: тот, у кого болит - не знает как подступиться к проблеме, а тот, кто это умеет - занят реально более важными вещами, да и донести важность проблемы у него не получается. | + | Практически формат использовался как '''решение проблемы снизу''', в любом месте, где она возникает. Роль формата А3 в том, что при этом любой сотрудник, заинтересованный в проблеме, но не имеющий навыка решения, получает форму, следуя которой он может продвигаться, обсуждая проблему на всех уровнях и получая доказательную базу для обсуждения с руководством. Я знаю, что этого часто не хватает: тот, у кого болит, — не знает, как подступиться к проблеме, а тот, кто это умеет, — занят реально более важными вещами, да и донести важность проблемы у него не получается. |
| | | |
− | Шаблон А3 есть в инете, они брали уже как-то адаптированный из книги Тома Поппендик и Генриха Книберга. А3 Problem Solving Template. Важно, что заполнять его надо так, чтобы понял генеральный директор (условно), а не техническим сленгом - тогда с высокой вероятностью поймут все, с кем будете обсуждать. Начинали они с реально бумажного шаблона, и пока ты в пределах офиса бумага с карандашом для обсуждений - удобнее. Но у них много офисов разработки и с выходом за пределы офиса они переходили в вики, и там же рисовали графы root cost analysis, расшаривая рабочий стол при обсуждении. | + | Шаблон А3 есть в Инете, они брали уже как-то адаптированный из книги Тома Поппендик и Генриха Книберга. А3 Problem Solving Template. Важно, что заполнять его надо так, чтобы понял генеральный директор (условно), а не техническим сленгом, — тогда с высокой вероятностью поймут все, с кем будете обсуждать. Начинали они с реально бумажного шаблона, и пока ты в пределах офиса, бумага с карандашом для обсуждений — удобнее. Но у них много офисов разработки, и с выходом за пределы офиса они переходили в Wiki, и там же рисовали графы Root Cost Analysis, расшаривая рабочий стол при обсуждении. |
| | | |
− | == Теория Ограничений для ИТ: информационные ограничения и управление временем - Андрей Степенко == | + | == Теория Ограничений для ИТ: информационные ограничения и управление временем (Андрей Степенко) == |
| | | |
− | Это был весьма странный и неожиданный доклад. Начался с того, что кроме физических ограничений, которые надо учитывать, используя теорию ограничений, существуют информационные. И в результате проекты с большим бюджетом не могут быть сделаны, потому что процедура принятия решений оказывается долгой и становится узким горлом. Правда, с мест качали, что, может это тоже физическое ограничение, связанное с отсутствием способных людей. Но, все-таки по разным причинам так может быть. | + | Это был весьма странный и неожиданный доклад. Начался с того, что кроме физических ограничений, которые надо учитывать, используя теорию ограничений, существуют информационные. И в результате проекты с большим бюджетом не могут быть сделаны, потому что процедура принятия решений оказывается долгой и становится узким горлом. Правда, с мест качали, что, может это тоже физическое ограничение, связанное с отсутствием способных людей. Но, все-таки, по разным причинам так может быть. |
| | | |
− | В качестве позитивных примеров, как эти ограничения можно обойти, приводились open source проекты, в которых система принятия решений распределена. Правда, без подробностей внутреннего устройства. Но с общим тезисом, что это потому, что там люди увлечены делом, и сознание находится в согласии с деятельностью. А еще ум расслаблен и незашорен. И с этого места Андрей перешел к тому, что есть такая техника - цигун - которая позволяет расслабляться и приводить сознание в спокойное и эффективное состояние. Нам немного про цигун рассказали, а потом были практические занятия. Прикольно. Но, по моему, не по делу. Может, потому, что я и так хорошо прихожу в эффективное рабочее состояние... | + | В качестве позитивных примеров, как эти ограничения можно обойти, приводились Opensource проекты, в которых система принятия решений распределена. Правда, без подробностей внутреннего устройства. Но с общим тезисом, что так происходит, потому что там люди увлечены делом и сознание находится в согласии с деятельностью. А еще ум расслаблен и не зашорен. И с этого места Андрей перешел к тому, что есть такая техника — цигун — которая позволяет расслабляться и приводить сознание в спокойное и эффективное состояние. Нам немного про цигун рассказали, а потом были практические занятия. Прикольно. Но, по-моему, не по делу. Может, потому, что я и так хорошо прихожу в эффективное рабочее состояние... |
| | | |
− | А кроме цигуна Андрей еще сказал, что есть такой GTD Аллена. Одним из эффектов которого - достижение бесстрессового состояния, что тоже повышает результативность мышления. | + | А кроме цигуна Андрей еще сказал, что есть такой GTD Аллена. Одним из эффектов которого является достижение бесстрессового состояния, что тоже повышает результативность мышления. |
| | | |
| [https://www.mindmeister.com/ru/335748479/ Mind Map доклада] | | [https://www.mindmeister.com/ru/335748479/ Mind Map доклада] |
Строка 180: |
Строка 182: |
| = Разработка документации = | | = Разработка документации = |
| | | |
− | А еще на конференции было два практических кейса, касающися документации. | + | А еще на конференции было два практических кейса, касающихся документации. |
| | | |
− | == Гибкая разработка пользовательской документации - Сергей Рогачев == | + | == Гибкая разработка пользовательской документации (Сергей Рогачев) == |
| | | |
− | Проблема документирования - известно-плохо-решаемая. Ребята применили известные подходы - включение в итерации, включение в DoD для userstory и трассировка фичи-документация. И у них заработало. | + | Проблема документирования — известно-плохо-решаемая. Ребята применили известные подходы — включение в итерации, включение в DoD для Userstory и трассировка фичи-документации. И у них заработало. |
| | | |
− | Что интересно в докладе - достаточно подробные документы, как у них организовано. Например, в описании DoD указано, что именно надо не забыть поправить (типа, часто Title забывают поправить), а отдельно - какие самые частые нарушения. Трассировку делали через автосборку на TFS из Word. И приведенные примеры покрывают не только документирование - поскольку оно тесно связано с остальным процессом. А заглянуть в организацию процесса у других - всегда интересно. можно почерпнуть новые идеи. | + | Что интересно в докладе — достаточно подробные документы, как у них организовано. Например, в описании DoD указано, что именно надо не забыть поправить (типа, часто Title забывают поправить), а отдельно — каковы самые частые нарушения. Трассировку делали через автосборку на TFS из Word. И приведенные примеры покрывают не только документирование, поскольку оно тесно связано с остальным процессом. А заглянуть в организацию процесса у других — всегда интересно, можно почерпнуть новые идеи. |
| | | |
− | И они поделились отдельным инструментом, который они используют. TeamSolution TeamSpec - плагин к VS. Они сделали отдельный WorkItem Document Item и именно там пишут документацию. Плагин это собирается в Word, а еще позволяет там редактировать с сохранением изменений в исходный Document Item. | + | И они поделились отдельным инструментом, который они используют. TeamSolution TeamSpec — плагин к VS. Они сделали отдельный WorkItem Document Item и именно там пишут документацию. Плагин это собирается в Word, а еще позволяет там редактировать с сохранением изменений в исходный Document Item. |
| | | |
− | == Разрушители мифов: Agile и аутсорс - Инга Юрьева == | + | == Разрушители мифов: Agile и аутсорс» (Инга Юрьева) == |
| | | |
− | В докладе рассказывалось о процессах документирования и локализации в Лаборатории Касперского. Проблема возникла после того, как они вышли на международный рынок. И основная версия выходит на 6-8 языках, а через 2-3 недели - еще 30-50 дополнительных языков. Работы по локализации были переданы из отдела в отдел документирования. При этом разработка, естественным образом, часто идет до последних дней, но документацию и локализацию надо успеть сделать. Еще одна особенность - в работе участвует достаточно много внешних сотрудников, поскольку для хорошего перевода нужно редактирование носителями языка. | + | В докладе рассказывалось о процессах документирования и локализации в Лаборатории Касперского. Проблема возникла после того, как они вышли на международный рынок. И основная версия выходит на 6-8 языках, а через 2-3 недели — еще 30-50 дополнительных языков. Работы по локализации были переданы из отдела в отдел документирования. При этом разработка естественным образом часто идет до последних дней, но документацию и локализацию надо успеть сделать. Еще одна особенность — в работе участвует достаточно много внешних сотрудников, поскольку для хорошего перевода нужно редактирование носителями языка. |
| | | |
− | Процесс был первоначально построен под водопадную разработку. А потом, с внедрением agile в разработке - перестроен с его учетом. Правда, их пугали - что agile и аутсорс несовместим, и качество упадет ниже допустимого. Но реально agile повлиял не слишком - из-за того, что разработка велась до последних дней, многое в процессе уже было. Но вы целом было рассказано достаточно много подробностей и особенностей, касающихся построения процесса. А основа успеха - тщательный подбор персонала по soft skill - культуре, коммуникациям, мотивации... И внешних сотрудников они держат на постоянной основе, перейдя от аутсорса к аутстафу. | + | Процесс был первоначально построен под водопадную разработку. А потом, с внедрением Agile в разработке — перестроен с его учетом. Правда, их пугали, что Agile и аутсорс несовместим и качество упадет ниже допустимого. Но реально Agile повлиял не слишком — из-за того, что разработка велась до последних дней, многое в процессе уже было. Но в целом было рассказано достаточно много подробностей и особенностей, касающихся построения процесса. А основа успеха — тщательный подбор персонала по Soft Skill — культуре, коммуникациям, мотивации... И внешних сотрудников они держат на постоянной основе, перейдя от аутсорса к аутстафу. |
| | | |
− | {{wl-publish: 2013-10-12 22:32:35 +0400 | MaksTsepkov }} | + | {{wl-publish: 2013-10-12 22:19:35 +0400 | MaksTsepkov }} |
| + | {{replicate-from-custiswiki-to-lib}} |
| [[Категория:Конференции]] | | [[Категория:Конференции]] |
Текущая версия на 20:49, 16 октября 2013
Серия осенних конференций началась с AgileKitchen. В конце месяца будет SECR с Иваром Якобсоном, потом — SQAdays во Львове с отдельным днем европейских докладчиков, а в начале декабря — SPMconf в Казани. Это — те, на которых я планирую быть, чтобы услышать, почувствовать новые тренды отрасли, узнать новые практики. И удачное начало этому было положено на AgileKitchen в эту пятницу, на территории Лаборатории Касперского.
Несмотря на название и позиционирование как обмен мнениями «на кухне», это было достаточно серьезное мероприятие. И по числу участников — думаю, было около сотни, хотя могу ошибаться, — которые сидели в большом зале, объединенном из трех переговорных с тремя большими экранами, и по уровню организации. И, главное — по характеру выступлений. На AgileKitchen выносятся темы, которые сейчас на острие развития, не успели обрасти серьезными теориями и практиками, но которые пробуют изучать и применять. И люди обмениваются опытом. А еще — там делятся практическим опытом решения задач, которые почему-то не становятся менее актуальными, несмотря на, казалось бы, давно известные подходы к решению. Их решают в конкретных условиях, и каждое новое решение имеет свои особенности, дает какой-то новый опыт, который тоже интересно обсудить.
Собственно, обсуждение практического опыта — самая важная составляющая мероприятия. И его было много: в перерывах между докладами, на OpenSpace, после конференции.
UPD. Материалы конференции
Мотивация и коммуникации
Обзор выступлений я на этот раз начну с темы мотивации и коммуникации, которая была темой сразу нескольких докладов.
Motivation 3.0: что вы должны знать для работы с командой (Алексей Пименов)
Алексей Пименов работает в ФИНАМ. Он рассказывал об эволюции теории мотивации и исследованиях в этой области. О том, что правильная мотивация для творческих задач, которыми занимаются ИТ-шники, возникает, когда ты находишься «в потоке». А это означает, что подходы, основанные на различных 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, где тоже делал доклад про Gamification. По-русски это называли как «геймификация», однако слово имеет всякие неправильные оттенки, поэтому теперь Максим предпочитает полную русификацию термина.
Начал он с того, что понимание многими игрофикации как раздачи ленточек, вымпелов и других наград — есть, в целом, профанация идеи. Для нее даже специальный термин есть — бейджификация. А профанация это потому, что быстро сваливается в формальность, нет азарта и состояния потока.
Игрофикация — игровая значимость реальных рабочих активностей. И она помогает работе за счет увлечения людей, а еще - за счет того, что доносит в игровой форме до людей правильные приоритеты. Потому что нет проблемы нехватки времени, есть только проблема неверной расстановки приоритетов.
Максим привел три конкретных игры, которые были разработаны и применяются, или планируются к применению для решения конкретных производственных задач.
Первая — track2win. Метафора автомобильной гонки, 12 этапов по месяцам. Ты едешь на машине, плюс собираешь награды. При этом машинки двигаются основной работой, это можно завязывать на багтрекер или другие рабочие показатели. А вот награды связаны с дополнительными активностями, поощряемыми компаниями, например, с выступлениями на конференциях и публикациями. Дальше вопрос тонкой настройки и балансировки. Включая нескольких измерений лидерства. Игра реально используется, по словам докладчика, отрицательных эффектов — не замечено. Есть люди и ситуации, когда игра не действует, но при этом производительность соответствует тому, что было без игры, а не ниже. Пока игра — чистый PvP, то есть конкуренция, они думают, как добавить другие элементы, чтобы была командная работа. А еще — готовят версию с ролями, чтобы разработчики могли соревноваться с тестировщиками, например.
Вторая игра «Коробки», ее запускают для Одноклассников. Цель — устранить технический долг, обеспечить исправление мелких ошибок, за которые берутся неохотно. Идея — каждый месяц вываливается «ящик Пандоры» — коробка ошибок для устранения за заданное время «разбора коробки». Ошибки — персонифицированные, ты помогаешь конкретному пользователю с его проблемой. А еще — нарабатываешь скилы. При этом техника прохождения может быть различной, можно соревноваться в количестве — тогда люди будут брать то, что хорошо умеют, а можно — через «чек-пойнты», разнородные ошибки, если хотим прокачивать кроссфункциональность.
Еще есть игра «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 and Theory) — Essence of Software Engineering: Kernel and Language. Я о нем знаю из разных источников, поэтому указанное в описании доклада, услышанное на докладе и узнанное ранее будет перемежаться. А еще — после доклада было много обсуждений, и часть мыслей оттуда.
Основная мысль авторов — проанализировать имеющееся описание разнообразных процессов и методов разработки софта на полном жизненном цикле с тем, чтобы создать язык для их формального описания, и — описать на этом языке имеющиеся методы и практики. И как идеальный результат — вы получаете возможность их сравнить, это во-первых, а во-вторых, — конструировать на их основе собственные процессы и методы. При этом за счет формального описания вы сможете достаточно быстро описывать новым сотрудникам и другими интересантам, чем ваши процессы отличаются от стандартных, а при проведении изменений — чем целевое состояние будет отличаться от того, что есть сейчас. И, наконец, при конструировании можно будет использовать имеющиеся практики из библиотеки, то есть пользоваться опытом индустрии, а не конструировать с нуля.
Пока все подобные описания выполнялись просто текстом, наличие формального языка упрощает ситуацию. Тем более, что, учитывая уроки UML, в язык сразу заложена графическая нотация для эффективного представления. А учитывая развитие Agile-методологий, которые достигли успеха во многом благодаря простоте представления, отличавшей их от тяжелых описаний традиционных методологий, авторы предприняли специальные усилия для упрощения методологии, пусть пожертвовав выразительными средствами и сложностями моделей.
Как идея все это звучит хорошо. Но вызывает опасения, что опять получится нечто громоздкое и слабоприменимое. Глава рабочей группы, которая все это создала, — Ивар Якобсон — один из создателей UML и RUP. И с этим тоже связаны опасения. UML в простых проявлениях — используется много, а вот как полноценный язык — не очень. А на смену RUP как раз и пришел Agile. Но, глядя на результат сейчас, можно сказать — он вдохновляет на использование. Он очень свежий, появился только в этом году, поэтому о полноценном использовании пока говорить рано. Но его пробуют применить в своих проектах. А еще — в обучении, и там он оказался весьма эффективен, потому что позволяет связать все аспекты деятельности в единое целое и дает пути, по которым можно пробовать идти без практического опыта ведения проектов, наполняя содержанием своего модельного или реального проекта.
В докладе был краткий обзор Essence и источников, а практический опыт как раз больше касался знакомства, собственных попыток применения и обучения.
Обзор я совсем кратко повторю. Для начала — терминология. Она во многом оригинальная, и это авторами сделано сознательно. Оригинальная она там, где использование существующих терминов вызывало бы нежелательные коннотации, связанные с применением термина в рамках существующих методологий и процессов и привела бы к потере существенных оттенков смысла. Там, где этого нет, — брали существующий термин, поэтому, например, Customer и Stakeholder — остались. Зато появились Alpha и Endeavor.
Все описание мира разделено на три больших части:
- Предметы - это альфы и их экземпляры, рабочие продукты;
- Деятельность, Activity Space;
- B Competence.
Альфа, для которой придумана расшифровка Abstract Level of Progress Health Attribute — это очень абстрактное понятие. Это нечто, что имеет состояния, по изменению которого мы можем судить о продвижении (Progress) или здоровье (Health) нашей деятельности. И это — идеальный предмет, тип, у которого в реальности возникают экземпляры (Instance) — это рабочие продукты (Work Product). Альфы имеют последовательность состояний, с состоянием связан набор признаков (Check List), которые должны быть зафиксированы для того, чтобы альфа его получила. И связана разнообразными ассоциациями с другими альфами. Деятельность — совершается над экземпляром альфы — рабочим продуктом — или несколькими, и что-то в них изменяет, в результате они могут изменить свои состояния. А компетенции — это способность определенные действия производить. Это если совсем кратко на абстрактном уровне.
На конкретном уровне программной инженерии все поле альф делится на три области.
- Customer — это окружающий мир, заказчики и интересанты.
- Solution — это решение, предмет-результат деятельности, программная система.
- Endeavor — это сама деятельность. В этом месте ранее употребляли слово «Проект», однако Essence описывает деятельность на полном жизненном цикле, а на этапе эксплуатации проекты занимают весьма ограниченное место. Говорят, в рабочей группе SEMAT есть представитель, занимающийся эксплуатацией, и она тщательно вымарывает слово «проект»по площади.
И Essence говорит, что для описания создания софта вам потребуется в этих областях минимально 7 (семь) альф:
- Возможности (Oportunity) и Стейкхолдеры в окружающем мире;
- Требования и Програмная система (Software System) в области решения;
- Работы (Work), Технологии работы (Way-of-Work) и Команды в Endeavor.
Больше — можно. И можно описывать подтипы. Но вот меньше — нельзя.
Дальше для всех основных альф описаны состояния — на полном жизненном цикле. Например, для стекйкхолдеров это Выявлены - Представлены - Вовлечены - В согласии - Удовлетворены развертыванием - Удовлетворены работой системы. Обратите внимание на два последних: это тоже состояния стейкхолдеров. И, естественно, помимо прямого пути возможен откат по графу. Состояние фиксируется для каждого отдельного стейкхолдера или для каких-то групп персонификаций, для всех вместе — как вы построили свое описание.
И это образует Kernel — ядро программной инженерии. Включая карточки чек-листов для состояний. А дальше есть библиотека — описания имеющихся практик и методов. На языке и в понятиях ядра описаны распространенные методы Scrum, User Story и Multi-Phase Waterfall, показано, как выстраиваются комбинации, описаны расширения базовых альф для бизнес-анализа, разработки и управления задачами, и так далее. Например, в расширении для бизнес-анализа наряду с Возможностями и Требованиями появляются Нужды (Need), которые становятся механизмом для движения Возможностей по состояниям. Авторы утверждают, что все известные методы создания и сопровождения программных систем являются комбинацией из менее чем 250 практик. Число большое, но обозримое. И все их можно описать в предложенном формализме и, более того, они это сделают. В обсуждении доклада неоднократно всплывали методы ITIL, их формализации пока вроде не видели (что не означает, что их нет).
Кроме текста стандарта, который достаточно сух, есть книга Ивара — Essence, которая более нацелена на практическое применение. Там есть практические кейсы, причем в вариантах, пригодных как организации обучения с передачей сути, так и для постановки формального процесса, понимаемого через деятельность. При масштабировании надо и то и другое, обучение через деятельность — гораздо более быстрое, и понимание сути не является необходимым для всех.
На сайте Ивара http://www.ivarjacobson.com/ доступно описания практик, а также готовые карточки чек-листов. В русском пространстве метод активно осваивает Анатолий Левенчук, публикуя посты в своем блоге, одновременно адаптируя и расширяя метод на системную инженерию. Он полагает, что это — определенный прорыв и именно в силу простоты изложения и формализма, не взирая на сопутствующие этому ограничения. У него есть перевод терминологии и сделан перевод карточек. Параллельно и взаимодействуя работает русское отделение SEMAT, которое тоже ведет перевод стандарта и книги Ивара. Словарь доступен здесь, работа идет в тесном контакте с основным SEMAT.
С готовыми артефактами библиотеки и связано возможное применение стандарта сразу. Вы можете просто распечатать карточки и читать их, сравнивая с ними свой процесс. Как сказал Юрий, сначала есть ощущение, что читаешь очевидные и известные вещи, пока не добираешься до пунктов, о которых сам почему-то не задумывался :) И часть этих пунктов можно сразу применять, и в работе и даже включая в договора. Юра так уже делал. Конечно, такой договор сложнее заключить, но по нему легче работать. Более того, ему уже реально приходилось апеллировать к этому в разборках. При чем отношения с заказчиком сохранились, и даже увеличилось уважение со стороны заказчика, а еще тот начал договора читать :)
А еще карточки можно применять в обучении, и это Юра тоже делал на Физтехе. Потому что в разных курсах студентам дают различные составляющие процесса создания ПО, а комплексная картинка не возникает. Карточки позволяют ее сложить, причем сразу в достаточно конкретном виде, пригодном для того, чтобы двигать свой проект.
За дальнейшими ссылками и содержанием отсылаю к слайдам Юры, которые он уже выложил. А в обсуждении, откуда начать знакомиться, возникла идея, что тут неплохо сработает обучение бросанием в воду. Берешь один из последних постов Левенчука, например, этот и копаешь по ссылкам в прошлое и на стандарты, пока не станет понятным. А на SECR можно будет не только услышать Ивара, но и пообщаться с ним в дискуссионном уголке.
Опыт применения A3 в компании Skype (Алексей Ильичев)
A3-анализ — это подход к решению стратегических проблем, применявшийся в «Тойоте». Суть его в том, что под одну проблему заводится лист формата А3, на котором коротко изложена суть проблемы, анализ и контр-меры. Алексей рассказывал о том, как в компании Skype они пробуют применять этот метод на трех практических кейсах.
Кейсы: проблемы с дизайнерами, из-за запаздывания работы которых возникали сложности с релизами, проблема с разрешением на использование Opensource-библиотек и организация работы с QuickBuild.
Сразу скажу, что во всех случаях проблемы решались просто от их осознания и обсуждения. В случае с Opensource вообще оказалось, что ответственные лица готовят документ, и через полгода будет счастье. Только ситуация была такова, что полгода ждать было нельзя и нужно было временное решение, и проведенный анализ как раз обосновывал остроту ситуации. Подробно описывать кейсы я не буду, интересующиеся могут посмотреть запись, когда она появится.
Практически формат использовался как решение проблемы снизу, в любом месте, где она возникает. Роль формата А3 в том, что при этом любой сотрудник, заинтересованный в проблеме, но не имеющий навыка решения, получает форму, следуя которой он может продвигаться, обсуждая проблему на всех уровнях и получая доказательную базу для обсуждения с руководством. Я знаю, что этого часто не хватает: тот, у кого болит, — не знает, как подступиться к проблеме, а тот, кто это умеет, — занят реально более важными вещами, да и донести важность проблемы у него не получается.
Шаблон А3 есть в Инете, они брали уже как-то адаптированный из книги Тома Поппендик и Генриха Книберга. А3 Problem Solving Template. Важно, что заполнять его надо так, чтобы понял генеральный директор (условно), а не техническим сленгом, — тогда с высокой вероятностью поймут все, с кем будете обсуждать. Начинали они с реально бумажного шаблона, и пока ты в пределах офиса, бумага с карандашом для обсуждений — удобнее. Но у них много офисов разработки, и с выходом за пределы офиса они переходили в Wiki, и там же рисовали графы Root Cost Analysis, расшаривая рабочий стол при обсуждении.
Теория Ограничений для ИТ: информационные ограничения и управление временем (Андрей Степенко)
Это был весьма странный и неожиданный доклад. Начался с того, что кроме физических ограничений, которые надо учитывать, используя теорию ограничений, существуют информационные. И в результате проекты с большим бюджетом не могут быть сделаны, потому что процедура принятия решений оказывается долгой и становится узким горлом. Правда, с мест качали, что, может это тоже физическое ограничение, связанное с отсутствием способных людей. Но, все-таки, по разным причинам так может быть.
В качестве позитивных примеров, как эти ограничения можно обойти, приводились Opensource проекты, в которых система принятия решений распределена. Правда, без подробностей внутреннего устройства. Но с общим тезисом, что так происходит, потому что там люди увлечены делом и сознание находится в согласии с деятельностью. А еще ум расслаблен и не зашорен. И с этого места Андрей перешел к тому, что есть такая техника — цигун — которая позволяет расслабляться и приводить сознание в спокойное и эффективное состояние. Нам немного про цигун рассказали, а потом были практические занятия. Прикольно. Но, по-моему, не по делу. Может, потому, что я и так хорошо прихожу в эффективное рабочее состояние...
А кроме цигуна Андрей еще сказал, что есть такой GTD Аллена. Одним из эффектов которого является достижение бесстрессового состояния, что тоже повышает результативность мышления.
Mind Map доклада
Разработка документации
А еще на конференции было два практических кейса, касающихся документации.
Гибкая разработка пользовательской документации (Сергей Рогачев)
Проблема документирования — известно-плохо-решаемая. Ребята применили известные подходы — включение в итерации, включение в DoD для Userstory и трассировка фичи-документации. И у них заработало.
Что интересно в докладе — достаточно подробные документы, как у них организовано. Например, в описании DoD указано, что именно надо не забыть поправить (типа, часто Title забывают поправить), а отдельно — каковы самые частые нарушения. Трассировку делали через автосборку на TFS из Word. И приведенные примеры покрывают не только документирование, поскольку оно тесно связано с остальным процессом. А заглянуть в организацию процесса у других — всегда интересно, можно почерпнуть новые идеи.
И они поделились отдельным инструментом, который они используют. TeamSolution TeamSpec — плагин к VS. Они сделали отдельный WorkItem Document Item и именно там пишут документацию. Плагин это собирается в Word, а еще позволяет там редактировать с сохранением изменений в исходный Document Item.
Разрушители мифов: Agile и аутсорс» (Инга Юрьева)
В докладе рассказывалось о процессах документирования и локализации в Лаборатории Касперского. Проблема возникла после того, как они вышли на международный рынок. И основная версия выходит на 6-8 языках, а через 2-3 недели — еще 30-50 дополнительных языков. Работы по локализации были переданы из отдела в отдел документирования. При этом разработка естественным образом часто идет до последних дней, но документацию и локализацию надо успеть сделать. Еще одна особенность — в работе участвует достаточно много внешних сотрудников, поскольку для хорошего перевода нужно редактирование носителями языка.
Процесс был первоначально построен под водопадную разработку. А потом, с внедрением Agile в разработке — перестроен с его учетом. Правда, их пугали, что Agile и аутсорс несовместим и качество упадет ниже допустимого. Но реально Agile повлиял не слишком — из-за того, что разработка велась до последних дней, многое в процессе уже было. Но в целом было рассказано достаточно много подробностей и особенностей, касающихся построения процесса. А основа успеха — тщательный подбор персонала по Soft Skill — культуре, коммуникациям, мотивации... И внешних сотрудников они держат на постоянной основе, перейдя от аутсорса к аутстафу.
Репликация: База Знаний «Заказных Информ Систем» → «Максима Цепкова/2013-10-12: Впечатления с AgileKitchen»
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
![](/skins/custisru/headline_right.gif) |