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

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

About the author

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

Activity

Recent comments

Disclaimer

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

© Copyright 2008-2018

Основные антипаттерны в софтверной разработке

Антипаттерны организации и управления: Аналитический паралич (Analysis paralysis): Неоправданное внимание и затраты времени/ресурсов на стадию анализа. Дойная корова (Cash cow): Прибыльный и успешный продукт, высокая прибыль от которого зачастую приводит к чрезмерной расслабленности в разработке новых версий продукта или новых продуктов. Разработка комитетом (Design by committee): Результат вклада в разработку многих участников, но отсутствие единого видения. Эскалация обязательств (Escalation of commitment): Неспособность отказаться от решения даже когда доказана его ошибочность. Драконовские меры (Management by perkele): Авторитарный стиль управления, отвергающий инакомыслие. Moral hazard: Отделение человека, принимающего решения, от последствий этих решений. Управление грибами (Mushroom management): Стиль управления, при котором работникам предоставляется минимум информации и эта информация искажается (управлять грибами - содержть в темноте и прикрмливать навозом) . Управление основанное на числах (Management by numbers): Уделение избыточного внимания численным критериям управления, когда они неважны или стоимость их получения слишком высока Дымоход (Stovepipe): Организационная структура, при которой потоки информации циркулируют преимущественно вверх-вниз, но не горизонтально, между подразделениями. Замкнутость на продавце (Vendor lock-in): Чрезмерная зависимость системы от внешней компоненты. Сваливание расходов (Cost migration): Перенос расходов на проект к уязвимому отделу или бизнес-партнёру. Путь камикадзе (Death march): Все знают, что проект обречён, кроме главы, вплоть до "дня X". Также применяется для стиля руководства, когда сотрудники вынуждаются к сверхурочной работе для достижения нереальных сроков. Расползание рамок (Scope creep): Дозволение рамкам проекта расти без должного контроля. Groupthink: Никто не хочет выдвигать идеи, противоречащие комфортному консенсусу. Дым и зеркала (Smoke and mirrors): Демонстрация заказчику заранее заготовленных "обманок" вместо рабочей функциональности. Раздувание ПО (Software bloat), Функции для галочки: Каждая следующая версия продукта требует всё больше системных ресурсов без явной выгоды для пользователя. Ползущий улучшизм (Creeping featurism): Добавление новых улучшений в ущерб качеству системы. Продолжительное устаревание (Continuous obsolescence): Выделение непропорционально больших усилий портированию системы в новые окружения. Bystander apathy: Дизайн или требования неверны, но те, кто это знают, ничего не предпринимают по этому поводу, т.к. для этого необходимо вовлечение большего числа людей. Tester Driven Development: Новые требования к продукту возникают из отчётов об ошибках. Я тебе это говорил (I told you so): Когда игнорируется предупреждение эксперта, являющееся оправданным Единственный знающий человек (Single head of knowledge): ЕЗЧ (SHOK) применим в том случае, когда единственная личность во всей организации контролирует жизненно-важную область ноу-хау или информации о внутренностях системы. Рыцарь на белом коне (Knight in shining armor): РНБК (KISA) происходит тогда, когда личность, которая не совершает ошибок, появляется на сцене и пытается починить всё, без сообщений о том, какие изменения он/она сделал/сделает и почему. Gold plating: Работа над проектом после момента, когда уже усилия перестают приносить прибыль или создавать добавочную стоимость. Антипаттерны дизайна и реализации:  Большой комок грязи (Big ball of mud), Проблема йо-йо (Yo-yo problem), Спагетти-код (Spaghetti code): Структура системы отсутствует или трудно поддаётся пониманию. Бензиновая фабрика (Gas factory), Ненужная сложность (Accidental complexity), Inner-platform effect, Раздувание интерфейса (Interface bloat): Неоправданное усложнение дизайна системы, излишняя гибкость или универсальность. Инверсия абстракции (Abstraction inversion): Не предоставление реализованных функций, необходимых пользователям, что вынуждает их реализовывать эти функции заново с помощью функций более высокого уровня. Database-as-IPC: Использование базы данных для обмена соосбщениями между процессами там, где можно использовать более легковесные способы. Затычка на ввод данных (Input kludge): Отсутствие коректной обработки возможного неверного ввода. Магическая кнопка (Magic pushbutton): Написание бизнес-логики в коде пользовательского интерфейса (например в обработчике события нажатия на кнопку). Гонки (Race hazard):Ошибка в определении последовательности различных порядков событий. Базовый класс-утилита (BaseBean): Наследование класса-утилиты вместо делегирования к нему. Вызов предка (Call super): Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка. Circular dependency: Ненужная прямая или непрямая взаимная зависимость между объектами или модулями. Блоб (Blob), Божественный объект (God object): Концентрация слишком большого количества функций в одиночной части дизайна (классе). Объектная клоака (Object cesspool): Повторнае использование объектов, чьё состояние не удовлетворяет (возможно неявным) условиям повторного использования. Паблик Морозов (Object orgy): Предоставление неоправданного доступа к внутренним свойствам объекта. Полтергейст (Poltergeists): Объекты, чьё единственное предназначение — передавать информацию другим объектам. Sequential coupling: Класс, требующий вызова его методов в строго определённом порядке. Действие на расстоянии (Action at a distance): Неожиданное взаимодействие между далёкими частями системы. Накопить и запустить (Accumulate and fire): Установка параметров подпрограмм в наборе глобальных переменных. Слепая вера (Blind faith): Недостаточная проверка корректности исправления ошибки или результата работы подпрограммы. Лодочный якорь (Boat anchor): Сохранение более не используемой части системы. Активное ожидание (Busy spin): Потребление ресурсов процессора во время ожидания события, обычно при помощи постоянно повторяемой проверки, вместо того, чтобы использовать систему сообщений. Cargo cult programming: Использование паттернов и методик без понимания причин. Проверка типа вместо интерфейса (Checking type instead of membership, Checking type instead of interface): Проверка того, что объект имеет специфический тип в то время, когда требуется только определённый интерфейс. Инерция кода (Code momentum): Сверхограничение части системы путём постоянного подразумевания её поведения в других частях системы. Кодирование путём исключения (Coding by exception): Добавление нового кода для поддержки каждого специального распознанного случая. Таинственный код (Cryptic code): Использование аббревиатур вместо мнемоничных имён. Error hiding: Перехват сообщения об ошибке до того, как она показывается пользователю, в следствие чего пользователь не получает сообщения об ошибке или получает бессмысленное сообщение. Expection handling: Использование системы исключений для реализации бизнес-логики системы. Жёсткое кодирование (Hard code): Внедрение предположений об окружении системы в слишком большом количестве точек её реализации Мягкое кодирование (Soft code): Патологическая боязнь жёсткого кодирования, приводящая к тому, что настраивается всё что угодно, при этом конфигурирование системы само по себе превращается в программирование. Поток лавы (Lava flow): Сохранение нежелательного (излишнего или низкокачественного) кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия. Loop-switch sequence: Кодирование последовательности шагов с помощью цикла и оператора выбора (switch). Магические числа (Magic numbers): Включение чисел в алгоритмы без объяснений. Программирование методом копирования-вставки (Copy and paste programming): Копирование (и лёгкая модификация) существующего кода вместо создания общих решений. Дефакторинг (De-Factoring): Процесс уничтожения функциональности и замены её документацией. Золотой молоток (Golden hammer, Silver bullet):  Сильная уверенность в том, что любимое решение универсально применимо. Фактор невероятности (Improbability factor): Предположение о невероятности того, что сработает известная ошибка. Преждевременная оптимизация (Premature optimization): Оптимизация на ранних стадиях в ущерб хорошему дизайну, сопроводимости и иногда даже реальной эффективности системы. Programming by permutation (или "programming by accident"): Попытка достижения нужного результата путём последовательного изменения кода и проверки помогает ли это. Изобретение колеса (Reinventing the wheel): Разработка собственного решения вместо применения существующего. Изобретение квадратного колеса (Reinventing the square wheel): Создание собственного плохого решения, когда существует хорошее. Ад зависимостей (Dependency hell), DLL-ад (DLL hell): Проблемы с совместно испльзуемыми билиотеками по причине различий в версиях одной и той же библиотеки   Источники 1. Anti-pattern on wikipedia.org 2. Антипаттерн на wikipedia.org

Posted by Vitalii Tsybulnyk on Tuesday, December 22, 2009 4:27 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Учимся делегировать

Старая истина гласит “Если хочешь сделать что-то хорошо - сделай это сам”, однако это не всегда верно, когда дело касается управления проектами. Важно всегда помнить, что вы не можете всё сделать сам или "клонировать себя", поэтому умение делегировать является неотъемлемой характеристикой успешного руководителя проекта. Для некоторых руководителей делегирование воспринимается как потеря контроля (а значит и власти), ведь в конце концов ответственность за успешное выполнение задач лежит на руководителе. Однако помните, что власть должна исползоваться крайне осторожно, и делегирование "под постоянным контролем" может встретить сопротивление или даже саботаж в команде. Сохранение балланса между контролем и делегированием есть одно из ключевых умений хорошего руководителя. Вы должны использовать минимальное количество власти и контроля, необходимое для должного результата. Частые проверки прогресса важны для того, чтобы устранить проблемы как можно раньше, но слишком много проверок может быть интерпретировано как недоверие. Начните с минимального контроля и повышайте его если чувствуете что этого недостаточно. Никогда не злоупотребляйте своей властью и не пользуйтесь властью для личной выгоды, в особенности если вам никто не давал такого права. Когда делегируете обязанности и власть, старайтесь давать людям выбор, однако перед этим убедитесь, что все варианты приемлемы для вас, и не давите если выбор был сделан не так, как вам хотелось бы. Помните также, что уважение - залог успешного делегирования, и при отсутствии должной доли уважения делегирование может быть практически неосуществимой задачей. Существует несколько способов заслужить уважение подчинённых. Прежде всего, демонстрируйте способность и желание выполнять задачи самому, делегирование не должно выглядеть так, как будто вы просто сбрасываете на кого-то работу, которую не хотите делать сами. Далее, делитесь с подчинёнными общим планом действий и важностью задач вцелом, это даст возможность понять ценность задач для успеха проекта и относиться к ним более серьёзно. Старайтесь, чтобы работа помогала вашим подчинённым в достижении их собственных целей и интересов, а не только интересов проекта. Следующее не менее важное условие успешного делегирования - руководитель должен хорошо знать свою команду, чтобы не только хорошо понимать потребности и предпочтения каждого участника, но и эффективно использовать сильные стороны своих подчинённых, а также избегать ситуаций, когда задачу поручают тому, кто с ней заведомо не справится. И наконец, вознаграждайте за успешное выполнение задачи, однако помните, что похвала приносит пользу только если она сказана искренне. Как только вы начнёте успрешно применять все перечисленные стратегии, ваше руководство превратится в то, чем оно и должно быть: дайте другим людям возможность принимать решения и воплощать их в жизнь, в то время как вы, как руководитель проекта, контролируете среду протекания этого процесса.   Источники 1. Become Better at Delegation on www.project-management-knowledge.com 2. Delegate Without Losing Control on www.project-management-knowledge.com

Posted by Vitalii Tsybulnyk on Wednesday, December 16, 2009 5:54 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Искусство "хаопорядоченного" лидерства

Рассуждая в своей работе [1] о лидерстве и руководстве в современных командах и организациях, Ди Хок вводит понятие "хаопорядоченного" ('chaord' = 'chaos' + 'order') лидества. По его мнению, успешное руководство в самоорганизующихся, самоуправляющих, адаптивных, нелинейных, сложных организмах, коими являются современные огранизации и команды, должно гармонично сочетать многие зачастую противоречивые характеристики: хаоса и порядка, соперничества и взаимопомощи, теоретических знаний и практических умений. Результатами его умозаключений является перечень замечательных рекомендаций, которым по моему мненю должен следовать любой успешный лидер: - Власть: Власть никогда не используется. Если вы пользуетесь властью - вы никогда реально ею не обладаете. - Человеческие отношения: Когда имеете дело с подчинёнными, повторяйте про себя: "Ты для себя так же хорош, как и я для себя, следовательно мы равны". Когда имеете дело с вышестоящими, повторяйте про себя: "Я для себя так же хорош, как и ты для себя, следовательно мы равны". - Критицизм: Активная критика - это ценнейшее приобретение. Она позволяет без малейших затрат времени и усилий устранить наши промахи и ошибки, а альтернативным решениям быть высказанными. Мы только должны слушать внимательно, отсеивая всё, что идёт от незнания, зависти или злобы, и выделяя то, что действительно ценно. - Компенсация: Деньги не мотивируют ни лучших людей, ни лучшее в людях. Они могут арендовать тело и влиять на сознание, но они не могут тронуть сердце или душу, это подвластно только доверию, принципам и этике. - Эго, Зависть, Жадность и Амбиции: Четыре зверя, которые неизбежно поглощают своего хозяина. Задумаете прокатиться на их спинах - и вы закончите у них в желудке. - Должность: Считаете что подчинённые дожны мерять степень своего повиновения превосходством Вашей должности? К сожалению, при этом Вы теряете то уважение, которое Вы могли бы заслужить у них своим ежедневным вкладом, а без их уважения Ваше превосходство и влась деструктивны. - Ошибки: Маленькие беззубые зверьки, которых вы можете распознать, признать, исправить, научиться на них, и перерасти их. Если же нет, то они отращивают клыки и наносят смертельный удар. - Выполнение: Никогда не путайте активность и продуктивность. Важно не то, что происходит на вашем конце трубы, а то, что выходит из другого конца. Всё, кроме мыслей, суждений и дейтствий, так или иначе инфицировано бессмысленной деятельностью. Думайте! Рассуждайте! Действуйте! Дайте возможность другим делать то же! - Наем: Никогда не нанимайте или повышайте по собственному подобию. Глупо дублировать свои сильные стороны, но ещё глупее плодить свои слабости. Нанимайте, доверяйте и вознаграждайте тех, чья переспектива, способности и суждения радикально отличаются от Ваших. Приготовьтесь к тому, что для этого нужны выдающиеся скромность, толерантность и мудрость. - Креативность: Проблема заключается не в том, как вызвать новые, инновационные мысли в вашей голове, а в том, как выбросить старые прочь. Каждый ум - как здание, наполненное архаичной мебелью. Очистите уголки вашего сознания - и креативность быстро заполнит их. - Слушайте: Вы можете узнать многое, внимательно слушая что люди говорят, но ещё больше можно узнать из того, что люди не говорят. Слушайте тишину так же внимательно, как и звуки. - Суждения: Суждения - это мускулы, которые сознание тренирует через использование. Вы ничего не теряете, доверяя им. Если вы доверились им, и они оказались плохими, Вы быстро поймёте и улучшите их. Если Вы доверяли им, и они оказались верными - Вы быстро преуспеете. Если же они были верными, но Вы не доверились им - Вы будете горько об этом жалеть, т.к. были правы, но последовали чужим неверным суждениям к провалу. - Руководство: Управляйте собой, управляйте своими руководителями, управляйте равными себе и дайте своим людям делать то же самое.   Источники 1. Dee Hock The Art of Chaordic Leadership

Posted by Vitalii Tsybulnyk on Wednesday, December 2, 2009 4:24 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Как отстреливается большинство хороших идей

Очень наглядный эксперимент для демонстрации факта "отстрела" большинства хороших идей провёл Мэтью Мэй и описал результаты в своей работе [1]. На одном из проводимых им тренингов присутствовало около 75 человек с большим диапазоном старшинства от руководителей команд до топ-менеджеров, причём Мэтью зарание собрал и огласил информацию о степени старшинства каждого из присутствующих. Изначально упражнение заключалось в демонстрации "коллективного разума", когда "мы" оказывается умнее чем "я", и основывалось на сравнении результатов решения сложной проблемы коллективно и индивидуально. В качестве проблемы была выбрана известная "Проблема выживания на Луне", у которой есть правильное решение, предложенное и детально аргументированное NASA. Мэтью внёс в упражнение следующее изменение: на каждом столе он выбрал представителя с самой низкой должностью и сделал из них "подсадный уток", предварительно сообщив им правильное решение и его объяснение. Однако их задача при этом не изменилась - убеждать всех остальных более высокопоставленных членов команды в правильности своего решения. По итогом коллективного решения проблемы ни одна из команд не дала в итоге верного ответа. После последующего индивидуального решения проблемы Мэтью попросил встать тех, кто дал верный ответ (т.е. "подсадный уток") и объявил, что это те люди, кто предлагали верный ответ, но их идеи были задавлены или проигнорированы, вероятнее всего по причине их низкого ранга. "Я жалею что у меня не было на тот момент камеры, чтобы заснять багровые лица менеджеров" - пишет Мэтью. Конечно, этот эксперимент носил некоторую долю розыгрыша, однако проблема от этого не исчезает и не становится менее серьёзной. Более формальное исследование вопроса "отстрела" хороших идей изложено в [2].   Источники 1. Matthew E. May 'Mind of the Innovator: Taming the Traps of Traditional Thinking' 2. Michael Iva '100 Ways to Kill a Concept: Why Most Ideas Get Shot Down'

Posted by Vitalii Tsybulnyk on Tuesday, November 24, 2009 4:14 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Software Quotes

UNIX is simple. But It just needs a genius to understand its simplicity. -Dennis Ritchie   Before software can be reusable, it first has to be usable. -Ralph Johnson   Good judgment comes from experience, and experience comes from bad judgment. -Fred Brooks   It's hard enough to find an error in your code when you're looking for it. It's even harder when you've assumed your code is error-free. -Steve McConnell Code Complete   The trouble with the world is that the stupid are sure and the intelligent are full of doubt. -Bertrand Russell   If debugging is the process of removing bugs, then programming must be the process of putting them in. -Edsger Dijkstra   You can either have software quality or you can have pointer arithmetic. You cannot have both at the same time. -Bertrand Meyer   There are two ways to write error-free programs; only the third works. -Alan J. Perlis   Measuring programming progress by lines of code is like measuring aircraft building progress by weight. -Bill Gates   The first 90% of the code accounts for the first 10% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. -Tom Cargill   Programmers are in a race with the Universe to create bigger and better idiot-proof programs. The Universe is trying to create bigger and better idiots. So far the Universe is winning. -Anonymous   Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why it works. Programmers combine Theory and Practice: Nothing works and they don't know why. -Anonymous   The Six Phases of a Project: 1.  Enthusiasm 2.  Disillusionment 3.  Panic 4.  Search for the Guilty 5.  Punishment of the Innocent 6.  Praise for non-participants -Anonymous

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Tuesday, October 27, 2009 5:57 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Побеждаем ошибки

Я давно наблюдаю за тем, как люди допускают ошибки. И чем больше я это делаю, тем больше меня удивляет не то, что большинство людей (и я в том числе) допускает их постоянно. Самое странное для меня то, что многие люди каждый раз искренне удивляются, допуская ошибку: "Как это могло произойти? Как я мог этого не заметить / об этом не подумать?". И дальше происходит самое страшное: "Больше такого со мной не случится! Я буду внимательнее / дальновиднее / аккуратнее". Потом ошибки допускаются снова и всё повторяется. В результате ошибок не становится меньше, зато падает самооценка и мотивация. Лично я так не делаю и вам не советую. Лично я знаю точно, что я ошибаюсь, что к большому моему сожалению непогрешимость не входит в число моих талантов, как впрочем и в число талантов большинства знакомых мне (даже очень талантливых) людей. И я использую это знание: я никогда не делаю ставку на безошибочность свою или людей, с которыми я работаю. Как раз наоборот, я стараюсь всегда исходить из того, что если ошибка может произойти, то рано или поздно она происходит, поэтому я делаю всё возможное для того, чтобы ошибке негде было случиться:  - я не полагаюсь на свою память, если нужно что-то "просто запомнить", то такое решение скорее всего не для меня;  - я не полагаюсь на свою внимательность, например задачу типа "внимательно просмотреть" я стараюсь заменить на "использовать автоматическое средство";  - я никогда не заливаю исправление в коде (даже если это одна буква), предварительно не скомпилировав его и не проверив работоспособность и т.п. Конечно, бывают в жизни случаи, когда соблюдение вышеперечисленных правил не представляется возможным. Однако я продолжаю следовать своему правилу: я никогда не удивляюсь ошибкам (своим или чужим) и никогда не обещаю (и не требую) безошибочной работы. То, чего я требую от себя и от других, как раз прямо противоположно этому: никогда не полагаться на непогрешимость человека, а делать всё возможное для того, чтобы ошибке просто негде было произойти.

Categories: Development | Management
Posted by Vitalii Tsybulnyk on Wednesday, September 16, 2009 6:10 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Документирование и распределённый мозг команды разработчиков

Вопрос документирования в процессе разработки бесспорно заслуживает пристального внимания как один из наиболее важных. Мне столько раз приходилось слышать сетования на недостаточную документированность требований или технических решений, что наверно уже давно пора было бы принять решение "чем больше документации - тем лучше". Однако я бы с таким решением не спешил. Дело в том, что (как показывает практика) большинство софтверных проектов - это далеко не реализация точно заданных требований по заранее определённым техническим методикам. Такая удача - удел академической науки либо госзаказ для военной или космической программы. Большинство же современных коммерческих софтверный проектов активно эксплуатируют "софт"-составляющую процесса, а именно: и бизнес-, и технические требования к проекту как правило меняются очень динамично. Ответом на это стало появление динамических методологий, основная масса которых относится к документированию приблизительно следующим образом: "Документирования нужно ровно столько, сколько решит команда и спонсор для данного конкретного проекта" [1]. Второе открытие динамических методологий заключается в том, что документирование может быть выражено в различных формах. Наследие инженерных дисциплин сводило документирование к узкому классу инженерных артифактов, а именно "инструкция (алгоритм)" и "чертёж (диаграмма)". Большинство же гибких методологий, протестуя против инженерной сути софтверной разработки, предлагает более вольное трактование понятия "проектная документация" и включают в него все возможные артифакты, способные служить метками, по которым можно восстановить суть ценной для проекта информации, начиная c салфеток с набросками пользовательского интерфейса и заканчивая фотографиями доски или даже видеозаписями митингов или дискуссий [2]. Думаю для любого, кто хоть раз пытался поддерживать детальную "инженерную" документацию динамичного софтверного проекта в актуальном состоянии, данная идея звучит весьма заманчиво. Конечно же, она основана на том, что все вместе участники проекта на самом деле обладают всей необходимой информацией, им только нужны своего рода "ссылки" или маркеры, которые могут направить их к человеку, владеющему интересующей вас в данный момент порцией технических или маркетинговых деталей. Мне это напоминает гипотезу о распределеноом мозге муравьиной семьи, только здесь роль такой семьи выполняет команда по разработке софта. Из этой модели следуют и очевидные рамки её применимости:  - Чем хуже коммуникации, тем больше нужно маркеров, например для эффективной работы удалённой команды этих маркеров нужно больше всего.  - Чем строже формализм, тем больше нужно формальных документов взамен "распределённого знания", например для военных разработок роль "распределённого разума" незначительна.  - Чем выше риск потери части "распределённого знания" (уход или долгое отсутствие сотрудников), тем выше должно быть дублирование этих знаний и тем больше маркеров приходится задействовать.   - Чем больше новичков приходится подключать к проекту, тем больше маркеров и тем подробнее эти маркеры.   Источники 1. Alistair Cockburn 'How many work products are needed in software development?' 2. Alistair Cockburn 'The end of software engineering and the start of economic-cooperative gaming'

Posted by Vitalii Tsybulnyk on Sunday, September 13, 2009 7:13 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Лучшие практики удалённой разработки

К сожелению или к счастью, но оффшорный аутсорсинг и аутстаффинг уже стали неотъемлемой частью бизнес-модели современной разработки ПО. Ими пользуются компании всех "рангов" - от стартапов с командой из двух человек до софтверных гигантов. Обсуждение преимуществ и недостатков таких тенденций выходит за рамки данного поста, однако с учётом сложившейся ситуации мне представляется ценным сформулировать основные советы и рекомендации участникам процесса удалённой разработки. За последные несколько лет я побывал пожалуй во всех возможных ролях этого процесса, так что накопил некоторый собственный опыт в данной области, к тому же сегодня я буду апеллировать к наработкам ведущих мировых авторитетов [1]. Начну я с той ошибки, которую поначалу допускают многие: "В условиях нашей конкретной задачи переход на удалённую разработку ничего не меняет".  Каковы бы ни были условия вашей задачи, процесс удалённой работы радикально изменяет модели поведения участников такого процесса и их ощущения во время работы. Это не только подтвердит вам любой руководитель или разработчик, работавший удалённо, но и очевидно следует хотябы из того факта, что именно коммуникации (которые играют основную роль в процессе и несут основной вклад в успех) изменяются больше всего при переходе на удалённую работу. Нужно заметить, что большинство приведенных ниже рекомендаций хорошо бы соблюдать не только для удалённой разработки, однако именно расстояние делает их особенно важными:  - Старайтесь разделять команды по функциональности и модулям, а не по ролям - удалённая команда QA конечно тоже имеет право на существование, однако когда разработчик и тестировщих находятся близко друг к другу, эффективность растёт.  - Если кодом совместно владеют удалённые команды, то ежедневно собирайте автоматические билды - это позволит сделать вносимые изменения более прозрачными, а также оперативно устранять "поломанные билды" и юнит-тесты.  - Используйте вики для хранения общей информации. Рассчитывайте, что вам понадобится более детальное документирование.  - Пользуйтесь тестовыми скриптами для лучшего понимания требований - нет ничего более понятного для разработчика, чем код.  - Проводите совместные митинги по планированию итераций и регулярные статус-митинги.  - Комбинируйте различные виды коммуникаций - IM, аудиоконференции, видеоконференции, электронная почта, вики могут дать намного больший эффект при совместном использовании.  - Регулярно посылайте представителей от обеих сторон с личным визитом друг к другу - это позволяет улучшить комуникации, построить доверие и усилить обе команды.  - Бойтесь недооценить культурные, региональные и языковые различия - сюрпризы могут поджидать вас там, где вы даже не подозреваете.   Источники  1. Martin Fowler 'Using an Agile Software Process with Offshore Development'

Posted by Vitalii Tsybulnyk on Friday, September 11, 2009 2:21 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Паттерны управления рисками

Управление рисками - несомненно одна из главных задач руководителя проекта. Пожалуй никто не может похвастаться тем, что принимал когда-либо участие в "идеальном" проекте: технический уровень команды был достаточно высок, процесс разработки был выверен и отлажен , требования были детально согласованны и неизменны на протяжение всей работы. Все подобные "неидеальности" невероятно сложно предвидеть и устранить в начале проекта, поэтому в проектном менеджменте их относят в категорию рисков. Существует немало стратегий рискового менеджмента: инкрементная разработка, итерационная, спиральная, водопадная и другие. Все они направлены на то, чтобы получить новую информацию как можно раньше, с тем, чтобы как можно раньше выйти на путь успеха и уменьшить стоимость и время последующих корректировок курса. Можно даже сформулировать универсальную стратегию снижения риска провала проекта:  - внимательно следить за ходом проекта  - определять риски  - работать над устранением рисков в порядке убывания опасности для проекта И если первые два пункта более-менее вопросов не вызывают, то в последнем и заключена магия хорошего менеджмента. Как отреагировать на появление риска в уникальных условиях данного проекта? Как уменьшить риск, с которым ранее никогда не сталкивался? Как подкорректировать реакцию на риск, которая в прошлый раз оказалась неэффективной? Если бы все менеджеры всегда знали ответы на эти вопросы, количество проваленных проектов не превышало бы количество успешных, как это происходит сейчас. Однако есть и хорошие новости, которые заключаются в том, что существуют предложенные разными авторами наборы паттернов, проверенных опытом реакций менеджера на возникновение определённых рисков. Естественно, эти паттерны не могут подойти в 100% ситуаций, более того, они всегда потребуют определённой интерпретации в условиях конкретного проекта и конкретного риска. Однако такие паттерны способны дать определённое нулевое приближение, начальную рекомендацию, которая уже может быть пропущена менеджером через призму ситуации и превращена в готовое решение. Сегодня я приведу набор паттернов уменьшения рисков, предложенный Алистэром Коуберном в [1]: 1. Знания: Рассеивание тумана (Clear the Fog) Если вы не знаете риски и трудности проекта достаточно хорошо для того, чтобы разработать хороший план - попытайтесь выпустить хоть что-то, это даст вам понять в чём реальные трудности. Частные случаи: "Ранние и регулярные выпуски", "Прототип", "Микрокосм". 2. Знания: Ранние и регулярные выпуски (Early and Regular Delivery) Вы не знаете какие проблемы вам встретятся в процессе разработки - выпустите что-то как можно раньше и выясните то, чего не знаете. Выпускайте регулярно совершенствуясь каждый раз. 3. Знания: Прототип (Prototype) Вы не знаете как некотрые архитектурные решения себя поведут - разработайте отдельный испытательный прототип и понаблюдайте как он на самом деле работает. 4. Знания: Микрокосм (Microcosm) Вам нужно разработать реальный план, но вы никогда не занимались проектами такого рода - запустите 8-12 недельный "пилотный" этап и соберите данные о продуктивности и т.п. для вашего плана. 5. Командная работа: Целостное многообразие (Holistic Diversity) Разработка некоторого модуля требует разных умений, а люди имеют узкую специализацию - создайте команду из людей с разными умениями. 6. Продуктивность: Золотой рывок (Gold Rush) У вас нет времени ждать утверждённых требований - начните разработку немедленно, корректируйте её по последним требованиям еженедельно. 7. Владение: Один ответственный на продукт (Owner per Deliverable) Иногда над чем-то работает много людей, иногда никто - убедитесь что у каждого продукта (выпуска) есть ровно один ответственный. Частные случаи: "Владельцы функциональности и компонент", "Одна команда на задачу" 8. Владение: Ответственные за функциональность и компоненты (Function Owners / Component Owners) Если вы организовываете команду по компонентам, то страдает функциональность, и наоборот - убедитесь что за каждую функциональность и каждую компоненту кто-то отвечает. 9. Помехи: Кто-то всегда движется к цели (Someone Always Makes Progress) Помехи постоянно прерывают работу команды - убедитесь что кто-то движется к цели что бы не случилось. Частные случаи: "Одна команда на задачу", "Жертва", "Ежедневная забота" 10. Помехи: Одна команда на задачу (Team per Task) От команды требуется серьёзное отвлечение от основной задачи - пусть этим займётся часть команды, а основная команда продолжает идти к цели. 11. Помехи: Жертва (Sacrifice One Person) От команды требуется небольшое отвлечение от основной задачи - поручите это одному человеку. 12. Обучение: Ежедневная забота (Day Care) Ваши експерты тратят всё свое время на обучение новичков - выделите одного эксперта курировать всех новичков, остальные разрабатывают систему. В самой статье приводится детальное описание ситуаций с примерами и подробное объяснения механизма работы каждого паттерна, так что тем кто заинтересовался лучше ознакомиться со статьёй полностью.   Источники 1. Alistair Cockburn 'Project risk reduction patterns'

Posted by Vitalii Tsybulnyk on Saturday, August 29, 2009 5:18 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Разработка ПО как основанная на сотрудничестве игра

Когда в 1968 году на конференции НАТО впервые был введён термин “software engineering” для разработки ПО как одной из областей инженерии, эта классификация была скорее вызовом, стимулом для дальнейшей работы, чем основанной на реальном опыте моделью. Однако за неимением ничего лучшего она быстро прижилась, и на протяжении последующих 40 лет философы и методологи разработки ПО боролись с использованием этого подхода в основном по 4-м причинам: Такая классификация никак не отражает наиболее важные для успеха проекта вещи, такие как талант, мастерство, командное взаимодействие и коммуникация между людьми. Такой подход не соответствует историческим данным об успехах и провалах проектов, в частности противоречит более вероятному успеху проектов с менее строгими "церемониями" и с более "легковесным" с точки зрения правил и рамок процессом. После 40 лет использования разные люди и организации всё ещё трактуют термин и процесс "софтверной инженерии" совершенно по-разному. Ни термин, ни классификация не дают раельно эффективного направления работы в области разработки ПО, которое могло бы гарантированно (или хотябы вероятно) привести проект к успеху. Многие авторы предлагают свой собственный подход к этой проблеме. В этом посте я хочу поделиться моделью, предложенной Алистэром Коуберном [1]: Разработка ПО - это серия ресурсно-лимитированных, целенаправленных, основанных на сотрудничестве игр в изобретение и взаимодействие. Основной целью каждой игры является производство и развёртывание софтверной системы. По окончанию игры остаётся набор меток, которые помогут игрокам в следующей игре. Люди используют эти метки для напоминания, вдохновления и информирования друг друга во время следующего хода в этой игре, таким образом второстепенной целью игры является создание благоприятной ситуации для следующей игры. Основная и второстепенная цели конкурируют за ограниченные ресурсы. Такая модель действительно раскрывает все важные для успеха проекта проблемы: сотрудничество, коммуникации (а особенно их стоимость, доля и необходимое количество), индивидуальные таланты и умения, отношения между людьми-как-индивидуумами в парах и группах, ценность сохранения устоявшихся команд, уменьшающаяся отдача от детального моделирования и документирования [2], важность обучения и применения различных стратегий для различных обстоятельств. И хотя большинство словарей при определении термина 'игра' акцентируются на развлекательном аспекте (что и вызывает несогласие с игровой моделью Коуберна), смысл этого термина претерпел существенные изменения на протяжение последних десятилетий, так же как и отношение к удовольствию, получаемому участниками рабочего процесса от выполняемой ими работы. Именно необходимость получения этого удовольствия для успешной работы и приводит разработку ПО так близко к термину игры. Опуская детальную классификацию игр, обсудим лишь категорию, в которую попадает разработка ПО: это конечная (ограниченная достижением конкретной цели) игра, основанная на сотрудничестве. В этой же категории находится, например, альпинизм: конкретной целью является достижение вершины, а участники игры не конкурируют, а сотрудничают для достижения этой цели. После достижения цели как правило происходит оценка удовольствия, полученного от процесса, и анализ ошибок, результаты которого невероятно ценны для достижения последующих целей. Это как две капли воды похоже на разработку софта, только цель там своя - получение и развёртывание работоспособной системы. Второстепенная цель при этом точно та же: в процессе и по окончанию игры извлечь максимальную пользу и тем самым как можно лучше подготовиться к следующей игре. При этом большинство проектных команд ограничено во времени, деньгах и людях, так что полное достижение обеих целей врядлм возможно. Это и делает протекание каждой игры таким чувствительным к личностным характеристикам участников и (как следствие) абсолютно неповторимым.   Источники 1. Alistair Cockburn 'The end of software engineering and the start of economic-cooperative gaming' 2. Alistair Cockburn 'How many work products are needed in software development?'

Posted by Vitalii Tsybulnyk on Wednesday, August 26, 2009 2:06 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Инкрементная итерационная разработка

Для начала поговорим о понятиях:  Инкрементная (incremental) разработка - это стратегия планирования стадий проекта, при которой различные части системы разрабатываются в разное время, а затем интегрируются (в противоположность стратегии "большого взрыва", когда все части разрабатываются одновременно, а в самом конце разработки интегрируются). При инкрементной разработке вся система разбивается на отдельные компоненты или модули, разработка каждого из которых планируется и осуществляется отдельно во времени, с последующей интеграцией в систему по мере готовности. Итерационная (iterative) разработка - это стратегия планирования ревизий системы, во время которых система определённым образом дорабатывается или усовершенствуется (в противоположность стратегии, когда система планируется и создаётся сразу совершенной, идеальной). При итерационной разработке основным видом деятельности является усовершенствование, доработка существующей системы: не только производительности, качества кода и функциональных возможностей, но и требований, интерфейсов, технологий, архитектуры и алгоритмов. Отождествлять эти два подхода было бы такой же ошибкой, как и противопоставлять их друг другу. На самом деле, эти две стратегии абсолютно не противоречат, а наоборот, усиливают друг друга. Инкрементная разработка незаменима для больших систем, однако она сравнительно проста в планировании. Итерации сравнительно более сложно выделять и планировать, как следствие ими сложнее управлять (особенно для больших систем), однако например в условиях нечётких или изменчивых ребований они бесспорно необходимы. Таким образом, применение к сложной системе обоих подходов многократно усиливает каждый из них: разбивая всю систему на инкременты и применяя к каждому из них итерации, мы таким образом делаем процесс одновременно более управляемым и более гибким для переработок. Кроме того, самая рискованная и ответственная часть инкрементной стратегии - интеграция - перестаёт быть таковой как раз благодаря итерационному процессу.   Источники 1. Alistair Cockburn 'Using both incremental and iterative development'

Posted by Vitalii Tsybulnyk on Monday, August 24, 2009 2:11 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Методики успешных проектов: подрезаем хвост

Думаю, что методика "подрезания хвоста" (“trim the tail”) интуитивно используется многими менеджерами проектов, однако весьма полезно было бы ознакомиться с тем, как Алистэр Коуберн в своей статье [1] приводит довольно подробное описание и аргументацию эффективности этого подхода. Использование методики направлено на наиболее эффективное управление рисками и приоритетами в проекте путём правильной последовательности выполнения задач, что приводит к облегчению выбора между раннией поставкой менее функциональной версии продукта и поздней поставкой более полной версии. Согласно методике, стратегия работы над проектом состоит из двух основных стадий: 1. Как можно раньше определить наибольшие социальные и технические риски проекта (как правило, все и так это делают), разбить их на как можно более мелкие компоненты (задачи). Работать над этими "рискованными" задачами на как можно более ранней стадии проекта до перевода в статус "нерискованных". Таким образом происходит как можно более раннее накопление критических знаний о системе (рис.1). 2. Определить и расставить приоритеты самым ценным для бизнеса функциональным единицам проекта (как правило, все и так это делают) и работать над ними в порядке убывания приоритетности. Таким образом происходит максимально быстрое увеличение бизнес-ценности системы (рис.2). Рисунок 1: раннее накопление критических знаний о системе. Рисунок 2: быстрое увеличение бизнес-ценности системы. Перемещение менее приоритетных задач (например по повышению качества и усовершенствованию функциональности) в конец очереди выполнения приводит к тому, что в любой момент времени бизнес-ценность системы максимальна по отношению к затраченному времени. Кроме того, перемещение наименее рискованных и наименее ценных для бизнеса задачи в конец цикла разработки позволяет дать бизнесу выбор между раннией поставкой менее функциональной версии продукта (тем не менее содержащей наиболее ценную фунциональность) и поздней поставкой более полной версии (что в свою оченредь не влечёт больших технических или социальных рисков). Рисунок 3: отрезаем хвост. Это и состовляет наибольшую ценность подхода: спонсор в реальном времени получает безопасную с точки зрения рисков возможность "отрезать хвост" (рис.3): найти оптимальный для бизнеса балланс между временем выпуска системы и её фунциональной наполненностью.   Источники 1. Alistair Cockburn 'From Agile Development to the New Software Engineering'

Posted by Vitalii Tsybulnyk on Wednesday, August 19, 2009 5:30 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Антропология разработки ПО

В разработке ПО несколько абсолютно разных культур работают вместе. Это программисты, разработчики баз данных, дизайнеры пользовательского интерфейса, тестировщики, аналитики, менеджеры, спонсоры проекта, группа маркетинга и в конце концов конечные пользователи. Деление на группы происходит и в других измерениях: новички и эксперты, рациональные и интуиты и т.п. Внутри каждой такой группы пропагандируются свои ценности, которые могут вступать в противоречие с ценностями других групп, однако каждая культура имеет определённые формы защиты для своего выживания, т.к. групповые или культурные ценности как правило способствуют лучшему вкладу в дело проекта... Как правило, но не всегда. Обычной реакцией на обнаружение несоответствия ценностей является попытка изменить сами культуры. Например, убедить руководителя отменить все митинги и просто дать программистам работать над проектом "пока они всё не сделают", или попросить пользователей стать экспертами в ООП, или дизайнеров использовать формальные нотации... Группы пытаются изменить друг друга. Происходит это потому, что ещё никто и никогда не пытался создать некую карту групповых ценностей и выяснить:  - какие части групповых стратегий позволяют им успешно делать своё дело?  - какие ценности для них характеризуют успешность-неуспешность?  - что ещё влияет на успех каждой группы?  - какие ценности и культурные характеристики могут быть безопасно изменены?  - где проходит грань между гармонией и конфликтом культур?  - как выглядит полная карта суммарной системы ценностей всех участников? Результаты такой работы дали бы возможность: 1. Распознать все культуры, вовлечённые в проект, и их ценности. 2. Найти людей, способных работать по обе стороны разных культур и которые бы способствовать эффективной коммуникации культур и сглаживанию основных противоречий. 3. Информировать каждую из групп о целях и ценностях других групп, относиться к ним с должным вниманием и уважением и в то же время знать и использовать всё, что другая культура может им предложить. 4. Применить наработанные этнографические и антропологические техники для изучения каждой группы и обнаружения их сильных и слабых сторон. Коротко говоря, это дало бы возможность при организации работы над проектом использовать объективные факты вместо желаний и догадок, как это делается сейчас.   Источники 1. Alistair Cockburn 'What can OO programming learn from anthropology?'

Posted by Vitalii Tsybulnyk on Wednesday, August 19, 2009 4:04 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Как правильно проводить Scrum (stand-up) митинги

Основой для данного поста послужила статья Jason'а Yip'а 'It's Not Just Standing Up: Patterns of Daily Stand-up Meetings', пропущенная через призму моего собственного опыта ежедневных Scrum-митингов в Microsoft. Вот перечень нескольких основных принципов, без следования которым ваш Scrum-митинг наверняка потеряет львиную долю эффективности: Цели:    - Поделиться обязательствами. Это самая важная цель ежедневного stand-up'а, более важная, чем поделиться прогрессом или состоянием задач.  - Обсудить статус, прогресс и планы с командой и наблюдателями. Обсуждение статуса наиболее всего отличает stand-up от любого другого вида статус-митингов, т.к. во время stand-up'а члены команды сообщают статус друг другу, а не своему менеджеру. Обсуждение статуса также даёт возможность команде быть в курсе всего, чем занимается команда каждый день.  - Выявить препятствия, чтобы команда могла предпринять шаги по их устранению. Хороший stand-up должен создавать ощущение поддержки, любой намёк на обвинение или осуждение быстро останавливает людей от оглашения своих проблем во время stand-up'а. Более того, оглашённые проблемы обязательно должны быть решены или поручены тем, кто их может решить.  - Установить направление и приоритеты.  - Тим-билдинг. Нельзя забывать, что основной фокус stand-up'а - это всё-таки не задачи, а люди, и stand-up призван решать именно человеческие проблемы и трудности. Место и время:  - Продолжительность ежедневных stand-up'ов - не более 15 минут, т.к. после 15 минут среднестатистический человек начинает терять состредоточенность. Недопустимо потакание некоторым любителям поболтать и их "рассказыванию историй". Также не нужно немедленно решать возникшие проблемы. Обсудите только вопросы, удовлетворяющие целям stand-up'а, все остальные вопросы обсудите после митинга или вынесите на отдельный митинг. Для того, чтобы митинг не затянулся, проводите его стоя, что также придаёт дополнительную энергетику.  - Динамичность и энергетика, обусловленные короткой продолжительностью, должны давать заряд бодрости на весь день. Кроме того, желательно, чтобы конец митинга был тем-то чётко обозначен, например характерной фразой, т.к. это (в противовес постепенному осознаванию, что сказать больше нечего) позволяет сохранить энергетику и динамику митинга.  - Проводите ежедневный stand-up в одном и том же месте в одно и то же время. Не ждите опаздывающих, даже если это менеджер или лидер, митинг проводится для всей команды а не для какой-то отделной персоны.  - Проводите stand-up в начале дня. Если в команде гибкий рабочий график, проводите митинг в самом начале времени, к которому собираются все. Помните, что stand-up задуман как психологическое начало рабочего дня. Участники:   - Все члены команды должны принимать участие в Scrum-митинге. Если кто-то не может учавствовать лично, он может поучавствовать по телефону или его статус должен огласить другой член команды.  - К Scrum-митингам, как и к любым другим, нужно готовиться. “Что я делал вчера?... Не помню уже... Что я делаю сегодня?... Посмотрим по ходу...” - такого быть не должно, все должны чётко знать свои 'Вчера', 'Проблемы' и 'Сегодня'. Управление:  - Члены команды не рапортуют лидеру. Основа ежедневных stand-up митингов заключается в самоорганизации, хороший stand-up самоуправляемый, он больше похож на кофе-брейк, чем на митинг.  - Ведущий у митинга должен быть, но это не обязательно один и тот же человек, ведущий может сменяться по кругу или например зависеть от дня недели. Не поощряйте взгляд говорящего на ведущего, т.к. это похоже на отчёт перед одним человеком, а не всей командой.  - Все знают, кто должен говорить первым, для этого не нужна команда ведущего. Заведите правило наподобие "Первым говорит тот, кто пришёл последним" или любое другое. К сожалению, многие менеджеры, особенно имеющие существенный опыт руководства до перехода к Scrum, подсознательно тяготеют к несоблюдению многих из приведенных принципов, тем самым существенно понижая эффективность Scrum-митингов. Однако ответственность за эффективные stand-up митинги (как и за всё в Scrum) несёт вся команда, поэтому все её участники должны приложить максимум усилий для соблюдения хотябы большей части перечисленных идей.

Posted by Vitalii Tsybulnyk on Sunday, August 9, 2009 9:04 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Новые методологии программирования Мартина Фаулера

Сегодняшний пост пожалуй будет последним из короткого цикла о гибких (agile) методологиях. Сегодня у нас в гостях снова Martin Fowler (Мартин Фаулер), несдвигаемая глыба в области современного проектирования и архитектуры программных продуктов, со своей статьёй 'The New Methodology' ("Новые методологии программирования"). Статья является великолепным обзором истории и нынешного состояния мирового Agile течения (или точнее сказать потока). Первая часть статьи приводит предпосылки возникновения Agile: Привлекательность новых методологий для многих заключается в отсутствии бюрократизма, присущего монументальным методологиям. Новые методологии представляют собой попытку достичь необходимого компромисса между слишком перегруженным процессом разработки и полным его отсутствием. Иначе говоря, объема процесса в них как раз достаточно, чтобы получить разумную отдачу. При строительстве моста на работы по проектированию уходит около 10% от всей стоимости работ. Остальное - затраты на конструирование. В программных разработках время, которое тратится на кодирование намного меньше. Отсюда вопрос о сущности проектирования при разработке программных продуктов и его отличиях от проектирования в других областях инженерной деятельности. Каждый раз, когда я сталкиваюсь с проектом, в котором наблюдаются проблемы, я слышу одно и то же. Разработчики приходят и говорят: "Все проблемы из-за того, что заказчик постоянно меняет требования". В этой ситуации меня удивляет только одно - почему все этому удивляются. При разработке программных бизнес-приложений требования должны изменяться, это нормально. Вопрос только в том, что можно сделать по этому поводу. Оценить длительность процесса разработки ПО тяжело по нескольким причинам. Во-первых, создание программных продуктов представляет собой работу по проектированию, которую трудно планировать и оценивать. Во-вторых, быстро меняются исходные материалы. В-третьих, очень многое зависит от конкретных людей, которые выполняют работу, а людей всегда сложно прогнозировать и подходить к ним с какими бы то ни было мерками. Это приводит к довольно ироническому умозаключению: все заказчики полагают, что требования можно менять. В конце концов, в слове "software" присутствует слово soft. Итак, требования не просто могут меняться - они должны меняться. Нужно положить много сил и энергии, чтобы заставить заказчика четко зафиксировать свои требования. Сделать это еще сложнее, если заказчики когда-то сами баловались разработкой ПО - тогда они знают, что изменить программу несложно. Впрочем, даже если вам удалось получить четкий список требований, все равно вы обречены. В современной экономике ценность тех или иных свойств программных продуктов меняется слишком быстро. То, что является достаточным набором требований сегодня, оказывается устаревшим уже через полгода. Даже если заказчики могут предоставить стабильный список требований, мир бизнеса от этого не замрет. А ведь многие изменения в мире бизнеса совершенно непредсказуемы (тот кто скажет, что я не прав, либо лжет, либо уже заработал миллион, играя на бирже). Далее Фаулер переходит к некоторым деталям и сложностям построения или перехда на гибкий процесс:   Одна из серьезных ошибок - делать вид, что вы используете предсказуемый процесс, в то время как вам это не удается. Разработчики методологий плохо определяют граничные условия, то есть, те ситуации, в которых методология из годной переходит в разряд негодной. Большинство методологов хотят, чтобы их разработками пользовалось как можно больше людей, при этом они не осознают граничные условия и не информируют о них пользователей. В результате этого методология нередко используется в неподходящих условиях, например, предсказуемую методологию могут использовать в непредсказуемой ситуации. Да, искушение велико. Предсказуемость - очень ценное свойство. Однако если вы будете считать, что можете прогнозировать события, в то время как уже утратили способность это делать, то непременно окажитесь в ситуации, когда план работ создан заранее, а момент, когда он перестает соответствовать действительному положению вещей, уже упущен. И вот, вы видите, как план и реальность медленно расходятся в противоположных направлениях. Конечно, можно довольно долго создавать видимость того, что план все еще выполняет свою функцию. Но в какой-то момент это расхождение становится настолько серьезным, что план просто разваливается. Как правило, событие это весьма болезненное. Контракт с фиксированной стоимостью предполагает неизменность требований, а значит, использование предсказуемого процесса. Если использовать адаптивный процесс при нестабильных требованиях, обычная установка на фиксированную оплату уже не срабатывает. Попытка втиснуть адаптивный процесс в рамки фиксированной оплаты приводит к весьма неприятным конфликтам. При этом самое неприятное то, что заказчик пострадает ничуть не меньше компании-разработчика. В конце концов, заказчику не понадобился бы программный продукт, если бы того не требовал бизнес. Если он не получит этот программный продукт, бизнес пострадает. Итак, даже если заказчик не заплатит компании разработчику ничего, он все равно несет убытки. Более того, он теряет даже больше, чем если бы заплатил за готовую систему (зачем бы заказчику платить за нее деньги большие, нежели ее коммерческая стоимость?) Осуществлять адаптивный процесс на деле - непростая задача. В частности, для этого нужна очень хорошая команда разработчиков. При этом необходимо, чтобы команда не просто состояла из специалистов высокой пробы, но и умела слаженно работать. Здесь наблюдается интересная взаимосвязь: для адаптивного процесса нужна сильная команда разработчиков, но и большинство хороших специалистов тоже предпочитают адаптивный процесс. Другая ключевая идея заключается в том, что разработчики должны иметь возможность принимать все технические решения. Наибольшего выражения это достигает в ХР, где только разработчики могут устанавливать, сколько времени должно уйти на ту или иную работу. Многие руководители воспринимают такое управление техническим процессом как нечто совершенно невероятное. Адаптивный процесс требует равного разделения ответственности за осуществление проекта между разработчиками и руководством. Обратите внимание, я сказал "равного". Руководство продолжает играть свою роль, однако при этом отдает должное мнению разработчиков. Нет ничего хуже для разработчика, чем видеть, как плоды его кропотливого труда идут в мусорную корзину. Поэтому так важно знать, что у вас есть хорошие консультанты, которые могут постоянно общаться с разработчиками и обладают достаточными знаниями в своей области, чтобы разработчики могли на них положиться. Далее в статье приводится замечательный пересказ истории возникновения различных направлений Agile (XP, Scrum, Crystal, Lean, RUP) и их объединения в единый термин Agile. Статья непременно должна быть прочитана теми, кто работал, работает или собирается работать согласно Agile.

Posted by Vitalii Tsybulnyk on Sunday, August 2, 2009 5:26 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Динозавров - на пенсию!

Сегодня я поделюсь замечательной статьёй Джима Хайсмита (Jim Highsmith) "Устаревшие методологии - на пенсию!" ('Retiring Lifecycle Dinosaurs'), продолжающей серию постов о гибких (agile) методолоиях. Как и большинство статей по agile, статья строится на том факте, что методологии разработки программного обеспечения могут и должны быть не менее изменчивыми, чем бизнес требования, технологии и сами люди: ... темп развития технологий и бизнеса все убыстряется, и статические способы управления становятся непригодными. Старый мир был миром оптимизации, где правили эффективность, предсказуемость и контроль. Новый мир - это мир адаптации, в котором главное место отводится изменениям, импровизации и новым идеям. Такая дихотомия - оптимизация против адаптации - позволяет нам ясно представить себе будущее управления программными разработками. Автор приводит основы разработанной им адаптивной методологии ASD (Adaptive Software Development), которая позволяет изменять многие параметры процесса прямо по ходу проекта, адаптируясь к новым условиям и обучаясь на ошибках и недостатках: В ASD обычный статический жизненный цикл Plan-Design-Build (Планирование - Проектирование - Конструирование) заменен на динамичный - Speculate-Collaborate-Learn (Обдумывание - Взаимодействие - Обучение). Этот цикл ставит своей целью непрерывное обучение. Он связан с постоянными изменениями, повторными оценками, попытками предугадать неизвестное на текущий момент будущее проекта и требует тесного взаимодействия между разработчиками, тестировщиками и заказчиками. (Обратите внимание, что весь этот цикл не всегда представляет собой правильный круг. Даже при итеративном процессе можно иногда отклоняться в сторону, чтобы изучить неисследованные до сих пор области). Методология ASD построена на концептуальной базе теории сложных адаптивных систем. Она рассчитана на использование в экстремальных проектах, в которых превалируют быстрый темп разработок, непредсказуемость и частые изменения. Есть проекты, которые не могут считаться экстремальными, однако для всех остальных ASD подходит гораздо лучше, чем любой традиционный подход к разработке ПО. Такой подход меняет традиционную последовательность действий и приоритеты при выполнении проекта, ставя во главу угла обучение: Так, например, постмортемы (переводчик использовал это слово, я бы подобрал более литературный вариант вроде "разбор полётов") проекта очень просты по сути. Они служат исключительно для того, чтобы определить, что прошло хорошо, где были сбои, и, наконец, какие изменения необходимо произвести. Как ни странно, многие организации не делают постмортемы, поскольку подобный обзор проделанной работы непременно превращается у них в политические игры и взаимные обвинения. Очень часто, вместо того, чтобы спросить себя "чему нам надо научиться?" мы начинаем искать ответ на вопрос "кто в этом всем виноват?". Запомните, чтобы ваша организация стала адаптивной и гибкой, ей нужно в первую очередь стать организацией, где умеют и любят обучаться. Это и радикально преобразуют весь стиль управления:  Команды разработчиков должны взаимодействовать при решении технических проблем и при определении требований к системе. Им необходимо улучшать свою способность принимать совместные решения. Руководству, кстати, пора передать командам больше прав для принятия решений, так как постоянные изменения (и жесткий график работ) совершенно исключают традиционный стиль управления - Command - Control (Приказ - Контроль). При этом руководителей больше должно беспокоить то, как добиться наиболее эффективного взаимодействия и обеспечить согласованность выполняемых работ, нежели вопросы проектирования, тестирования и кодирования. Как мы уже говорили, сегодня для многих проектов (например, для тех, которые разрабатывают физически удаленные друг от друга команды или постоянно меняющиеся партнеры) наибольшую важность имеет то, как люди взаимодействуют между собой, и как они справляются с неизбежно возникающей взаимозависимостью. Для небольших команд, где все разработчики работают в непосредственной близости друг от друга, тесная взаимосвязь и согласованность работ может быть достигнута неформальными методами. Все можно решить во время беседы в коридоре или порисовав немного у доски. В больших проектах все не так просто. Вполне очевидно, что далеко не каждому понравится такой метод. Многие руководители, привыкшие к традиционным методам, при компонентном подходе почувствуют, что могут частично утерять контроль и влияние на процесс. В таком случае, им лучше пересмотреть свои идеи и соображения относительно прогресса проекта. Изложенный подход очень органично перекликается с подходами Мартина Фаулера к необходимости постоянного рефакторинга: В итеративном жизненном цикле "переделка" продукта занимает не меньше места, чем его "создание". На производстве все обстоит по-другому. Там специальные программы, следящие за качеством работы станков, помогают избежать "брака" (результата ошибки в процессе изготовления какой-либо вещи) и последующей его переделки. Однако в области программных (и прочих интеллектуальных) разработок дело обстоит несколько по-иному, чем на конвейере, где бездушный автомат каждые несколько секунд штампует одинаковые штуковины. Кстати, весьма вероятно, что сама штуковина была спроектирована и разработана с применением итеративного процесса. Компоненты же, как правило, претерпевают изменения на протяжении нескольких итераций. Это происходит из-за того, что заказчики сообщают разработчикам свои комментарии относительно продукта по мере его развития. Примечательно аргументируется необходимость жёстких временных рамок для успешного протекания процесса: ... говоря о жестких временных рамках, мы должны иметь в виду не столько время и сроки, сколько принятие сложных компромиссных решений. Когда тебя окружают постоянные изменения, нужно периодически задействовать некий фактор, который будет заставлять доводить начатое до конца. Кроме того, существование временных рамок заставляет команду разработчиков и клиентов постоянно пересматривать основные показатели проекта: его границы, расписание работ и поставок очередных версий, ресурсы, дефекты и т.д. Те команды, которые не могут (или не хотят) принимать быстрые решения и делать выбор, никогда не добьются успеха в экстремальных условиях. На закуску пару весьма красивых фраз из статьи, призванных убедить всех в необходимости перехода к новым методикам работы:  "Оптимизирующие" культуры видят мир в черно-белом свете. "Адаптивные" культуры, в отличие от них, признают наличие серого. Они понимают, что планирование эфемерно, а контроль практически невозможен. "Адаптивные" культуры осознают, что успеха можно достичь, лишь испробовав несколько различных альтернативных вариантов, учась как на успехах, так и на ошибках. Они знают, что изучать новое часто не менее важно, чем использовать в работе давно привычное. ... разработка ПО - вовсе не механический, а органичный, нелинейный и недетерминированный процесс. Нужно изменить базовые принципы, на которых организации строят свою работу при решении сложных проблем, а также начать применять новые, связанные с ними, практики. Перейти из разряда оптимизирующих культур в разряд адаптивных означает сделать шаг в будущее, а не прозябать в прошлом.

Posted by Vitalii Tsybulnyk on Friday, July 24, 2009 5:22 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Каждой методологии - свое время

Сколько себя помню - всегда руководствовался принципом Алистэра Коуберна (Alistair Cockburn) "Каждому проекту своя методология" ( 'Methodology per project'). Неудивительно, что "продолжение" этого принципа в виде статьи "Каждой методологии - свое время" ('Just-in-time methodology construction') вызвало у меня немалый интерес. Русский перевод названия на мой взгляд немного неточен, я бы перевёл как "Построение методологии по ходу проекта", однако существующий перевод весма оправдан своей созвучностью со статьёй-предшественницей. Данная статья базируется на ещё одной известнейшей статье Алистера - "Люди как наиболее важные компоненты процесса разработки ПО" ('Characterizing people as non-linear, first-order components in software development'), о которой я уже писал Идея статьи проста, очень логична, и в то же время революционна: Коль скоро мы осознаем, что каждый проект заслуживает своей собственной методологии, то становится понятно, что любое изначальное предположение о ней является всего лишь догадкой. Это утверждение закладывает основу всем так называемым динамическим методологиям, т.е. методологиям, динамически изменяющимся по ходу проекта. Таким образом, поиск наиболее эффективной методологии сводится к поиску ответа на вопрос "как нам с течением времени трансформировать эту догадку в нечто действительно полезное для проекта". Ответ на этот вопрос, конечно же, существует не один. Коуберн выделяет следующие ключевые моменты:  - Разработка ведется инкрементным методом. Насколько я могу судить, это единственное необходимое методологическое условие.  - После каждого инкремента проводите общее собрание, на котором задавайте один-единственный вопрос: "Что мы могли бы делать лучше?"  - Берите за основу сильные стороны человеческой натуры Результатом работы Коуберна стала разработка целого семейства методологий Crystal. Метологии внутри этого семейства различаются по 3-м критериям: люди, критичность, приоритетность. Все методологии Crystal различаются по цвету, причем каждый цвет предназначен для определенных проектов и имеет свои собственные характеристики: Clear ("Прозрачная") для самых легких и небольших проектов, затем Yellow ("Желтая"), Orange ("Оранжевая"), Red ("Красная") и т.д., для больших команд, использующих более тяжелые методологии. Методология каждого цвета обладает своими собственными правилами и базовыми элементами. При этом каждая легка настолько, насколько это хорошо и правильно для данного типа проектов. Таким образом, изложенные в статье подходы - это не только одна из первых техник динамического (или своевременного) создания методологии, позволяющая выработать и "настроить" необходимые соглашения и стандарты по работе над проектом, эффективные методы общения и влиять на боевой дух команды, быстро избавляясь от малоэффективных методов работы, и опробовать новые до тех пор, пока не будет выработан некий приемлемый вариант. Кроме того изложенные в статье идеи позволяют создать целую "семью" или спектр методологий, которые бы имели в основе одни и те же базовые принципы, и которые можно было бы точно так же "настраивать" по ходу проекта.

Posted by Vitalii Tsybulnyk on Thursday, July 23, 2009 6:40 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Проектирования больше нет?

Martin Fowler (Мартин Фаулер) бесспорно является одним из самых уважаемых авторов в области современного проектирования и архитектуры программных продуктов. Его бестселлеры 'Refactoring: Improving the Design of Existing Code' и 'Patterns of Enterprise Application Architecture' - это, пожалуй, наиболее ценные книги, прочитанные мною за всю мою профессиональную жизнь. Недавно мне в руки попала замечательная статья Мартина с броским названием 'Is Design Dead?' (в русском переводе "Проектирования больше нет?"), о которой сегодня и пойдёт речь. Основная идея статьи - обсудить изменения в подходах к проектированию программных систем в связи с переходом к гибким (Agile) методологиям. Провокационное название статьи отражает тот факт, что многие Agile методологи (в первую очередь XP) преподносят дизайн системы как нечто возникающее эволюционно, в процессе непосредственного кодирования: Методология XP бросила вызов многим устоявшимся представлениям о разработке программного обеспечения. Пожалуй, наиболее противоречивой идеей является отказ от предварительного проектирования в пользу более эволюционного подхода. Для приверженцев новой методологии, это отказ от техник проектирования (например, UML), их принципов и паттернов. Незачем беспокоиться о проектировании, считают они. Достаточно внимательно "вслушиваться" в свой код, и проектирование образуется само собой. Фаулер, как выдающийся специалист в области проектирования, конечно же не соглашается с таким утверждением: В большинстве случаев, эволюционное проектирование - это нечто ужасное. В конце концов, все равно вместо дизайна системы вы получаете просто набор из специфических решений, каждое из которых затрудняет дальнейшие изменения в программном коде. Часто это вообще нельзя считать дизайном (и, уж конечно, такой дизайн никак нельзя назвать хорошим). Как говорит Кент, дизайн существует для того, чтобы дать возможность оперативно вносить в систему любые изменения. Если дизайн плох, то такая возможность исчезает. В результате вы будете иметь дело с энтропией программного продукта, и со временем и без того плохой дизайн системы станет еще хуже. Теперь вам будет не только сложнее вносить в систему изменения, но и отыскивать и исправлять ошибки, которые начинают множиться с катастрофической быстротой. Все это - кошмар разработок в стиле "code and fix", когда с течением времени исправление ошибок обходится все дороже и дороже. Однако одновременно являясь ярым приверженцем Agile и автором "библии" рефакторинга, Фаулер признаёт и рекламирует их эффективность: В методологии XP имеется много спорных моментов. Одним из ключевых таких моментов является то, что она базируется на эволюционном, а не предварительном проектировании. В основе этого утверждения лежит кривая стоимости изменений в программном продукте. XP строится на предположении, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой, оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют. У практик, с помощью которых осуществляется сглаживание, есть множество составляющих. В основе всех их лежит Тестирование и Непрерывная интеграция. Именно надежность кода, которую обеспечивает тестирование, делает возможным все остальное в этой методологии. Подобный эффект имеет и рефакторинг. В статье Фаулер пытается найти компромис, балланс между традиционными (и бесспорно необходимыми) методиками проектирования с одной стороны и Agile с другой: Джим Хайсмит ... использует аналогию с обычными весами. На одной чаше лежит предварительное проектирование, на другой - рефакторинг. В более традиционных подходах к разработке ПО перевешивает предварительное проектирование, так как предполагается, что передумать вы не можете. Если же стоимость изменений снизится, то часть проектирования можно делать и на более поздних стадиях работы, в виде рефакторинга. Это вовсе не означает отказа от предварительного проектирования. Однако теперь можно говорить о существовании баланса между двумя подходами к проектированию, из которых можно выбрать наиболее подходящий. Все эти основополагающие практики (непрерывная интеграция, тестирование и рефакторинг) создают новую среду, в которой эволюционное проектирование выглядит вполне убедительно. Впрочем, мы еще не выяснили, где же у этих весов точка равновесия. Лично я уверен, что не смотря на поверхностное впечатление, методология ХР - это не просто тестирование, кодирование и рефакторинг. В ней найдется место и для предварительного проектирования. Частично оно производится еще до написания первой строчки кода, но большая его часть приходится на то время, которое предшествует реализации конкретной задачи в течение итерации. Впрочем, такая ситуация представляет собой новое соотношение сил между предварительным проектированием и рефакторингом. Собственно, вся статья и посвящена нахожденю этого компромисса. Показывается полезность и органичность предварительного проектирования в XP, преимущества и критерии простого дизайна перед сложным при условии следования всем остальным практикам XP, показывается эффективное сосуществование принципа YAGNI ("You Aren't Going to Need It" - "Это вам не понадобится") и рефакторинга, применимость и ценность паттернов проектирования и даже UML в XP. Пожалуй я воздержусь от приведения здесь заготовленных мною цитат из статьи, а закончу пост настоятельной рекомендацией причитать эту статью. Она как никакая иная ценна для опытных разработчиков, архитекторов и менеджеров, переходящих на Agile методологии и имеющих какие-то сомнения по применимости своих знаний и умений в новых условиях. Статья не мене полезна и тем, кто имеет большой опыть например в XP, но не имеющих базисных знаний и умений в предварительном проектировании. И пожалуй наиболее полезна статья тем, чьи знания, умения и опыт равноценны в обеих сферах, т.к. изложенные концепции позволят наиболее эффективно и гармонично использовать и сочетать все эти бесценные умения в вашей работе.

Posted by Vitalii Tsybulnyk on Wednesday, July 22, 2009 7:06 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Принцип Питера - закон или признак?

В этом посте я хотел бы обсудить широко известный принцип Питера (Peter Principle), который гласит: В иерархической системе любой работник поднимается до уровня своей некомпетентности. Нужно признать, что несмотря на кажущуюся шуточность и ироничность, этот принцип имеет достаточно строгие обоснования:  - (1) Компетентные повышаются. Как правило, при появлении вакансии руководство выбирает кандидата из числа тех нижестоящих сотрудников, к которым нет претензий на их нынешней должности.  - (2) Некомпетентные не понижаются. На первый взгляд, может показаться, что никакой проблемы нет; достаточно просто возвращать сотрудников, не справляющихся с должностью, на предыдущее место. На практике же это обычно невозможно. Во-первых, это противоречит интересам руководителей, предложивших повышение сотрудника либо согласившихся с ним, — признав некомпетентность выдвиженца, они тем самым вынуждены будут признать свою ошибку. Во-вторых, предыдущая должность на момент обнаружения некомпетентности обычно уже бывает занята, так что возврат в исходное положение одного сотрудника приведёт к необходимости понижения или увольнения других, что обычно слишком сложно и тоже невыгодно. В результате, хотя некомпетентность сотрудника на новой должности может быть очевидна, его не понижают.  - (3) Отказ от повышения маловероятен. Кроме того, на принцип Питера ссылается немало серьёзных авторов и этот принцип повсеместно подтверждается на практике. Однако мне, к счастью, приходилось работать в компаниях (или командах), где этот принцип не соблюдается, поэтому на мой взгляд, принцип Питера сродни закону Мёрфи (Murphy's law) и закону Паркинсона (Parkinson's Law): и тот и другой упоминается тогда, когда необходимо убедительно аргументировать ошибки или провалы, просто сославшись на некий общеизвестный "всемирный закон неудачи". Я бы переформулировал принцип Питера в более оптиместичный признак Питера: Если в некоторой иерархической системе выполняется принцип Питера, то данная иерархическая система (или какие-то её подсистемы) находится в неоптимальном состоянии и требует реформирования. Или так: Достаточным признаком неоптимальности иерархической системы является выполнение в ней принципа Питера. Под оптимальностью здесь понимается что целью системы является эффективная работа (что верно далеко не для всех систем в этом суровом мире :-) )

Categories: Management
Posted by Vitalii Tsybulnyk on Thursday, July 16, 2009 5:29 AM
Permalink | Comments (5) | Post RSSRSS comment feed

Применение принципа суперсетов к Software Development'у

Общеизвестно из литературы, что переключение между задачами не только отнимает время, необходимое для того, чтобы вспомнить тебования, степень готовности задачи и детали реализации, но и пагубно сказывается на так называемом "потоке мышления", который прерывается при любом переключении внимания (в том числе и при переходе на другую задачу) и затем требует от 15 до 30 минут на восстановление. Исследования показывают, что, отвлекая разработчика каждые 15 минут, его продуктивность можно свести к нулю. Однако суровая правда жизни заключается в том, что очень часто бизнес диктует разработчику острую необходимость именно параллельного выполнения нескольких задач или как минимум регулярного переключения между задачами. В моей профессиональной практике бывали периоды, когда от меня требовалось работа над более чем 5 проектами одновременно, т.е. прогресс по каждому из проектов дожен был быть виден не реже, чем раз в два дня. Согласно общепринятому мнению, моя продуктивность в такие периоды должна была быть мизерной. Однако она была далека от мизерной. Более того, сравнивая мою суммарную продуктивность в эти периоды и в периоды "затишья" (работа над одной областью задач в течение недели или более), я каждый раз с удивлением обнаруживал, что суммарная продуктивность в периоды параллельной работы оказывалась даже несколько выше! Долгое время я приписывал этот эффект к своей "уникальности", т.к. для других разработчиков переключение между задачами действительно оказывалось губительным. Однако со временем я начал встречать других девелоперов, которые предпочитали работать над несколькими разнородными задачами или проектами, переключаясь между ними, нежели работать долгое время над одной задачей/проектом. Как правило, объяснение сводилось к тому, что долгая работа над одной задачей быстро становится скучным, утомительным занятием, и продуктивность резко падает, в то время как возможность переключения на другую задачу позволяет прогнать скуку и быстро отдохнуть от первой задачи. Крайнее проявление этого эффекта общеизвестно: засадите своих разработчиков за выполнение одноообразных (пусть даже и кажущихся поначалу интересных) задач одного и того же долгоиграющего проекта - и на втором году такой работы от вас сбежит 90% команды. Таким образом я утвердился во мнении, что регулярное переключение между выполняемыми задачами не только не вредно для продуктивности разработчика (при соблюдении определённых правил), но зачастую даже полезно. Видимо, для усталости мозга применим принцип суперсетов, общеизвестный среди спортсменов-тяжелоатлетов по отношению к мышечной усталости. Принцип этот заключается в том, что переключение нагрузки на другую группу мышц позволяет быстрее восстановиться, чем при обычном отдыхе, т.к. такое переключение уводит "центр усталости" в другое место, что значительно быстрее, чем просто ждать затухания этого центра со временем. Осталось только сформулировать те правила, которые позволят избежать падения продуктивности при таком переключении: 1. Не прерывайте поток мышления. Идея этого правила в том, что у мозга разработчика есть периоды "просветления", когда решение задачи складывается в единое целое. Прервите разработчика во время этого периода срочным вопросом или задачей - и скорее всего вы отбросите его работу на пару часов назад. Дайте ему возможность самому решать когда прерваться, это наступит достаточно скоро, т.к. после периода просветления всегда наступает период отдыха. Говоря проще, не звоните разработчику когда он занят задачей и не прерывайте его личным разговором, напишите ему письмо с пометкой "срочно" или оставьте сообщение иного рода. Во время периода отдыха он сам полезет проверять почту. 2. Дайте мозгу выбор. Не навязывайте жёстко порядок или время выполнения задач. Если вам нужно, чтобы нескольно задач было сделано - дайте разработчику самому выбрать к какой из них у него "лежит душа" именно сегодня и именно сейчас. Если речь идёт о прогрессе в нескольких проектах одновременно - не требуйте прогресса в каждом из них каждый день, задайте интервал в 2-3 дня, чтобы разработчик мог сам решить: разделить ли какой-то день между проектами/задачами или посвятить целиком одному проекту/задаче. Помните, что очень многое в вопросе эффективности зависит не только от сложности и специфики задачи, но и от настроения (физического и духовного состояния разработчика). 3. Минимизируйте давление и бюрократию. Не терроризируйте разработчика частыми вопросами о том, как идут дела, скорее всего это его будет только раздражать и отвлекать. Действуйте как в правиле 1 - дайте ему самому решить когда наступил удачный момент сообщить о своём прогрессе. По максимуму избавьте такого загруженного разработчика от бюрократии вроде детальных отчётов или двухчасовых командных митингов. В вялотекущих проектах это всё необходимо, чтобы держать руку на пульсе прогресса и направлять поток разработки в нужное русло, но для разработчика в режиме многозадачности это менее актуально: его задачи как правило более ясны и обозримы, его сложность другого рода - работать над этими задачами параллельно. 4. Повышайте нагрузку постепенно. Не бросайте разработчика, работавшего 3 месяца над одним проектом, сразу ещё на 3 других. Дайте один, через две недели ещё один. Дайте ему время настроиться и подрегулировать свой ритм. Ну и последнее, пожалуй самое важное: не рассчитывайте, что в режиме многозадачности может работать любой. Принцип суперсетов хорош для выносливого, тренированного атлета в отличной физической и психологической форме. Этот принцип категорически неприменим к новичкам и людям со слабым здоровьем. Но даже отличная форма и богатырское здоровье ещё не есть гарантия успеха. Есть люди, которым это просто не подходит.

Categories: Management
Posted by Vitalii Tsybulnyk on Friday, July 10, 2009 4:09 AM
Permalink | Comments (1) | Post RSSRSS comment feed