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-2017

Архитектура программного обеспечения с человеческим лицом

С задержкой в несколько месяцев наконец-то вышел №2 журнала RSDN за 2010-й год с моей статьёй "Архитектура программного обеспечения с человеческим лицом". Первая версия статьи была написана ровно год назад, в декабре 2009-го, и стала своеобразным итогом моего видения процесса разработки программного обеспечения в целом, и его архитектуры в частности, как гибкого, человеко-центристского, я бы даже сказал социального явления. Статья несколько раз дорабатывалась и даже переписывалась вплоть до весны 2010, когда и созрел окончательный вариант, отправленный в RSDN. Электронная версия статьи ещё не появилась на rsdn.ru, и мне не известны сроки её электронной публикации. К сожалению, RSDN не продаётся и не доставляется вне Росиийской Федерации, так что если вдруг у кого-то уже имеется бумажная копия журнала, или есть намерение приобрести, я был бы крайне признателен за сканы. Традиционная аннотация: В статье автор подводит итог и пропускает через призму собственного опыта основные человеческие аспекты архитектуры программного обеспечения. Рассматривается эволюционная природа архитектуры, особенно ярко выраженная в малых проектах и стартапах. Субъективность решений по поводу применения шаблонов проектирования в социальном контексте конкретного проекта приводит к наличию разных стилей применения этих шаблонов. Неоднозначность и многогранность роли архитектора подчёркивает и усиливает первоочерёдность человеческих факторов (личных и командных) для процесса принятия технических решений и проектирования архитектуры в проектах по разработке программного обеспечения.

Posted by Vitalii Tsybulnyk on Sunday, December 5, 2010 2:15 PM
Permalink | Comments (3) | Post RSSRSS comment feed

Контроль or not контроль?

Том ДеМарко не нуждается в отдельном представлении, на его книгах выросло не одно поколение руководителей и разработчиков, вот лишь некоторые их этих книг: 1986. Controlling Software Projects: Management, Measurement, and Estimates. Prentice Hall 1987. Peopleware: Productive Projects and Teams. With Timothy Lister. Dorset House. 1997. The Deadline: A Novel About Project Management. Dorset House. 2003. Waltzing with Bears: Managing Risk on Software Projects. With Tim Lister. Dorset House in March, 2003. Контроль над протеканием проектов разработки ПО - одна из ключевых тем его работ. Именно ему принадлежит ставшая крылатой фраза "You can’t control what you can’t measure" ("Вы не можете контролировать то, что невозможно измерить"). Однако сегодня лично мне очень приятно наблюдать, как этот действительно умный и талантливый человек меняет свою точку зрения на аспекты контроля вместе с изменением видения всего процесса в ИТ индустрии. Этот человек не боится признать, что был не прав, и статья [1] полностью посвящена такому признанию. Вот что он пишет: Моя ранняя книга по метрикам 'Controlling Software Projects: Management, Measurement, and Estimation' (Prentice Hall/Yourdon Press, 1982) сыграла важную роль в том, как многие инженеры-разработчики измеряли свою работу и планировали проекты. Под настроением провести некоторую рефлексию я спрашиваю себя: были бы мои советы в силе и сейчас, спустя столько времени? Верю ли я сам всё ещё, что метрики являются обязательным аспектом успешного процесса разработки ПО? Мой ответ: нет, нет и нет. По собственному признанию, Том не учитывал в своих работах о метриках многих важных и очевидных сегодня вещей: - не все метрики одинаково хороши и нужны- сбор качественных метрик стоит дорого (время, ресурсы)- метрики должны использоваться осторожно- разработка ПО отличается от естественных наук и её метрики намного менее точны в их попытке измерить те вещи, которые они должны отражать. Основной мыслью работ ДеМарко о метриках всегда было то, что контроль является пожалуй самым важным аспектом любого проекта по разработке ПО. Однако он сам признаёт сейчас, что это не так. Для понимания настоящей роли контроля, нужно различать два совершенно разных типа проектов:  - проект А при вложениях X приносит выгоду/прибыль 1.1*X- проект Б при вложениях X приносит выгоду/прибыль 50*X Очевидно, что контроль очень важен для проекта А и практически совершенно не важен для проекта Б. Это приводит нас к странному выводу, что строгий контроль очень важен для сравнительно бесполезных проектов и менее важен для полезных. Чем больше вы сосредотачиваетесь на контроле, тем более вероятно, что вы работаете над проектом, результирующая ценность которого сравнительно мала. Значит ли это, что можно успешно запускать проекты без особенного контроля? Вот что пишет ДеМарко:  Практически, да. Сначала выберите проект, в котором точный контроль не был бы так важен. Затем снизьте свои ожидания о том, как сильно вы сможете его контролировать. Как же управлять проектом без контроля? Руководите людьми и контролируйте время и деньги. Например, вы можете сказать своим тим-лидам: “У меня есть на уме дата окончания, но я даже не собираюсь вам её сообщать. Когда однажды я прийду и скажу, что проект заканчивается через неделю, вы должны быть готовы всё собрать и выпустить то, что у вас будет на тот момент как финальный продукт. Ваша задача - работать над проектом инкрементно, добавляя кусочки к целому в порядке их важности, и выполняя интерграцию, документирование и приёмочное тестирование такими же этапами.” Это может выглядеть как рецепт гибких методологий, но я ... просто проедлагаю это как подход к управлению. Я постепенно прихожу к выводу что software engineering - это идея, время которой пришло и ушло... Этот термин делает акцент на определённом наборе дисциплин, включая предопределённый процесс, проверки и разборы результатов, разработка требований, матрицы traceability, метрики, детальный контроль качества, строгое планирование с последующим слежением, стандарты кодирования и документирования. Всё это в целях последовательости в практиках и предсказуемости. Последовательность и предсказуемость всё ещё желательны, но они никогда не были наиболее важными вещами. Например, последние 40 лет мы мучались своей неспособностью заканчивать софтверные проекты в срок и в рамках бюджета. Но, как уже намекалось выше, это никогда не должно было быть высшей целью. Более важной целью является трансформация: создание ПО, способного изменить этот мир, или компанию, или то, как она ведёт свой бизнес. Лучше бы мы старались преуспеть в этой трансформации, пусть даже действуя вне рамок нашего контроля. Разработка софта всегда была и остаётся в чём-то экспериментальной. Само создание ПО не обязательно экспериментально, но его концепция - да. И это то, где дожен быть наш фокус. Это то, где наш фокус должен был быть всегда.    Источники 1. Tom DeMarco Software Engineering: An Idea Whose Time Has Come and Gone?

Posted by Vitalii Tsybulnyk on Friday, November 26, 2010 6:49 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Команда vs. Методология

В своих заметках я часто обращаюсь к теме гибких методологий разработки: я уже рассказывал как о многих успешных практиках, так и о наиболее распространённых ошибках и антипаттернах, способных свести на нет все достоинства методологии или даже привести проект к провалу. Однако чем больше я об этом думаю, пишу, выслушиваю отзывы и анализирую реальные примеры, тем больше убеждаюсь, что детали реализации гибкой методологии и используемые практики играют не такую уж большую роль в успехе или провале проекта. Успешная команда приведёт проект к успеху с практически любой методологией. Удачно подобранная методология несомненно способна сделать этот успех ещё более внушительным. Неподходящая методология скорее всего ухудшит результат, одако это врядли окажет решающее влияние на судьбу проекта. Провальная команда провалит проект с практически любой методологией. Даже наилучшая методология врядли способна на большее, чем просто растянуть агонию или смягчить провал. Неподходящая методология ещё быстрее выявит провальные тенденции и станет впоследствии "козлом отпущения", на которого и свалят вину от провала. Успешность или провальность команды формируется из множества факторов, большинство из которых относится к социальной, а не технической сфере, что невероятно затрудняет их анализ и коррекцию. Это и мотивация, и межличностные отношения и коммуникации, и успешность формирования лидерства в команде, и наличие в команде всех необходимых для успеха ролей, и стадия формирования самой команды, и многое другое. Для "нейтрализации" всех этих факторов (или по крайней мере большинства) были разработаны так называемые "тяжёлые" методологии. Например, большинство требований к сертификации процесса по ISO 9001:2000 как раз сводится к нейтрализации "человеческих" факторов и подмены их тем, что принято называть бюрократией. Для провальных команд использование подобных процессов и методологий - единственных путь привести проект к успешному завершению пусть даже ценой десятикратных затрат времени и ресурсов. Для успешных команд использование подобных методологий - существенная потеря времени и ресурсов, устранение которой (переход на более "лёгкие" методологии) способно многократно повысить общую производительность и результирующую успешность. Именно применение в успешных командах и оптимизация с их помощью успешных команд является основным сектором использования гибких методологий. К сожалению, большинство авторов не делают на этом никакого акцента, в скорее наоборот, стараются "притянуть" свою методологию "за уши" в сторону всеобщей применимости. Последствия такой интерпретации - желание всё большего числа менеджеров внедрить гибкую методологию в своей не очень успешной команде, и решить тем самым проблемы её неуспешности. Только вот результат обычно обратный и не заставляет себя долго ждать: проблемы становятся ещё более явными, провал приближается ещё более стремительно, неудача в итоге "списывается" на методологию. В связи со всем вышесказанным, хочу посоветовать всем менеджерам, задумавшим переход/внедрение гибкой методологии: 1. Постарайтесь ответить себе честно - успешна ли ваша команда? Есть ли в её работе "провальные" тенденции? Если команда с трудом приводит к успеху половину проектов - задумайтесь об утяжелении процесса или о новой команде. Если успешность команды близка к 100% - это то что надо, пора становиться гибче. 2. Никогда не переходите на методологию в середине проекта, особенно если в нём назревают серьёзные проблемы. Идеальное время перехода - между проектами или в самом начале проекта. Лучше всего "обкатать" методологию на небольшом проекте и маленькой команде, потом уже запусткать на серьёзные проекты и всю компанию. Если переход в середине проектного цикла неизбежен, делайте это только во время относительного  спокойствия, решив сначала основные проблемы и уведя проект от кризисных тенденций. Ну и конечно же, всё вышесказанное никак не отменяет других советов по переходу, если решение о переходе всё-таки принято и процесс запущен.

Categories: Agile | Management
Posted by Vitalii Tsybulnyk on Wednesday, November 3, 2010 7:56 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Антипаттерны перехода на гибкие методологии

В последнее время мне всё чаще и чаще приходится выслушивать негативные впечатления от моих друзей, знакомых и экс-коллег, связанные с переходом ИТ-компаний на гибкие (agile) метологии. В частности, наибольшую популярность (и как следствие, народное недовольство) снискал переход на Scrum. С грустью наблюдая, как порочиться доброе имя Scrum-методологии, и вдохновлённый идеями lean production, я решился написать эту заметку чтобы перечислить основные ошибки, допускаемые компаниями и командами при переходе на agile, в частности Scrum. Некоторые из этих ошибок я уже приводил в своих предыдущих статьях или комментариях к ним, но собрать и обсудить их в одном месте мне всё-таки показалось ценным и актуальным. Итак, основные антипаттерны перехода на гибкие метологии: 1. Непонимание роли руководства при внедрении методологии. Переход на многие гибкие методологии (Scrum, XP) подразумевает координальную смену задач и методов работы руководителей. В двух словах этот переход можно сформулировать как переход от управления к направлению, переход от приказов и указаний к рекоммендациям. Первая ошибка, которая допускается при таком переходе - подсознательное стремление сохранить за собой власть, ведущее ко всё тому же управлению, но замаскированному идеями agile. Вторая, не менее серьёзная ошибка прямо противоположна - неправильное понимание этого перехода может привести к устранению менеджеров от руководящих функций, когда руководитель перестаёт давать указания, но так и не начинает давать рекомендации. Роль руководителя при этом сводится к чисто формальным, секретарским функциям. Причиной этого может быть и неготовность руководителей давать аргументацию своему мнению (в старой модели им этого зачастую делать не приходилось) или боязнь невыполнения высказанных рекоммендаций. 2. Построение «системы», не обладающей необходимой гибкостью. Отсутствие опыта работы по новой методологии ведёт к тому, что новый процесс внедряется по инструкциям, буква к букве, что ведёт к негибкости и бюрократизации. 3. Начало внедрения не с «основ». При переходе на новые методологии руководство преследует конкретные выгоды, которые должна обеспечить методология: высокая производительность, качество и т.п. При этом некоторые практики нового процесса более очевидно ведут к этим выгодам, а некоторые - совсем не очевидно. В связи с этим возникает соблазн внедрить сначала более "выгодные" практики, а потом уже остальные. При этом не учитывается, что некоторые практики являются базовыми по отношению к другим, и внедрение вторых без первых невозможно. Пример: внедрение таких практик XP как рефакторинг или коллективное владение кодом без отработанной практики юнит-тестирования гарантированно приведёт к резкому ухудшению качества. 4. Изменяются рабочие места, но не меняются привычки. Провозглашение новых правил и следование этим правилам - это, как говорят в Одессе "две большие разницы". Недостаточное понимание новых идей всеми членами команды или слабое осознание выгод от перехода на новый процесс, слабая мотивация, отсутствие переходного периода с явно выраженными послаблениями в графике работ и количестве задач - это далеко не полный список ошибок, способных привести к тому, что новый процесс может соблюдаться лишь формально "для видимости", а в действительности саботироваться членами команды. 5. Все измерять (собирать данные), но ни на что не реагировать. Бесконечный анализ ситуации, вместо непрерывных улучшений («Паралитический анализ»). Большинство гибких методологий подразумевают сбор метрик и обязательную рефлексию - обсуждение ощибок, совершённых на предыдущем этапе, перед началом следующего. Распространённые ошибки в этой сфере - сбор метрик без их последующего анализа или неверная, слишком поверхностная интерпретация метрик; рефлексия без внесения изменений в процесс (или внесение симптотических, экстенсивных изменений). 6. Обходиться без поддержки. Отсутствие опыта работы команды по новой методологии и внедрение по букве инструкций таит много ошибок, неверных интерпретаций и недопонимания. Только участие в процессе перехода опытного инструктора, имеющего непосредственных опыт работы по новому процессу, может избавить команду от множества неверных поворотов и тупиков, или в отдельных случаях даже от построения совершенно неверной методологии.

Categories: Agile | Management
Posted by Vitalii Tsybulnyk on Monday, April 26, 2010 9:31 AM
Permalink | Comments (6) | 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

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

Для начала поговорим о понятиях:  Инкрементная (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

Рефакторим базу данных

Последние годы техника рефакторинга настолько прочно вошла в методологии процессов разработки ПО и инструментарий разработчиков, что всё чаще и чаще звучат утверждения о начале эры принципиально новых, эволюционных подходов к проектированию архитектуры. Пожалуй, одной из немногих областей, которая ещё прочно держит позиции предварительного проектирования, является структура базы данных. Действительно, изменение структуры базы данных по ходу жизненного цикла сопряжено с рядом существенных струдностей и затрат: это и миграция данных, и необходимость каскадного изменения кода приложений, использующих базу данных, и ряд других объективных трудностей. Однако, прогресс не стоит на месте, мыслители и идеологи рефакторинга и гибких методолий конечно же не мирятся с таким упущением. Наглядное тому подтверждение - некоторые книги и статьи Мартина Фаулера и его соратников. Одна из первых таких публикаций - это статья Фаулера 'Evolutionary Database Design', которая собственно и натолкнула меня на написание данного поста. Прежде чем говорить о применении техник рефакторинга по отношению к базам данных, нужно упомянуть некоторые ограничения, выход за рамки которых может существенно затруднить или даже сделать невозможными эти техники: 1. База данных исполюзуется в одном приложении или системе, это не интегрированная база данных для многих систем. 2. База данных не должна работать бесперебойно 24/7 Если данные условия соблюдены для вашего случая, можете смело рассчитывать применять к своей базе данных все те же подходы, которые уже успрешно применяете для всего остального кода проекта. Вот некоторые детали реализации рефакторинга применительно к базе даннных: 1. DBA и девелоперы должны очень тесно сотрудничать, т.к. рефакторинг базы данных с большой вероятностью влечёт изменения кода. Устраните все физические, психологические и бюрократические препятствия на пути их сотрудничества. Лично я всегда предпочитал DBA и девелопера в одном лице, котя конечно же это далеко не всегда целесообразно и возможно. 2. У каждого участника процесса есть своя копия базы данных для експериментов по нахождения оптимального рефакторинга. 3. Тестовая база данных - это не просто схема, она также содержит тестовые данные, близкие к реальным. Рефакторинг базы данных - это не только изменение схемы, он зачастую требует миграции и т.п. работы с данными. Чем больше данных содержит ваша тестовая база данных, тем более гладко пройдёт рефакторинг на продакшн базе. 4. Все изменения в базе данных по ходу работы над проектом - это рефакторинги, поэтому применяйте к ним те же шаги и правила, что применяете к обычному рефакторингу (см. Martin Fowler 'Refactoring: Improving the Design of Existing Code') 5. Автоматизируйте свой рефакторинг по окончанию работы над ним: сохраните скипт, производящий ваш рефактронг, с тем чтобы простым запуском этого скрипта вы могли выполнить рефакторинг на любой из копий базы данных, включая продакшн. 6. Сообщайте о изменнениях в базе всем разработчикам, лучше через автоматическую отправку е-мейла. 7. Выделяйте в своей системе явно выраженный слой доступа к данным, это позволит свести к минимуму последствия рефакторинга базы для остального кода (воспльзуйтесь одним из паттернов, описанных Фаулером в 'Patterns of Enterprise Application Architecture'). Ну и напоследок, хороший предварительный дизайн базы данных - это бесспорно очень хорошее начало для любого проекта. Однако последующие изменения неизбежны, и в нех нет абсолютно ничего страшного. Эволюционное изменение базы данных по ходу проекта не только уменьшит для вас затраты на предварительный дизнайн, но и избавит ваших разработчиков от необходимости подстраиваться под неудачный или устаревший дизайн базы данных. Следуйте приведённым выше рекомендациям и изменение базы данных превратиться для вас из страшилки для новичков в обыденную работу над доведением системы до идеала.

Posted by Vitalii Tsybulnyk on Tuesday, August 11, 2009 4:25 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

Люди как наиболее важные компоненты процесса разработки ПО

Alistair Cockburn - это один из моих любимейших авторов в области управления процессом разработки программного обеспечения, а его статья "Characterizing people as non-linear, first-order components in software development" - несомненная жемчужина в сокровищнице мирового достояния по этому вопросу (русский перевод статьи доступен здесь). Автор, эксперт в области методологий разработки ПО, более 20 лет посвятивший изучению этого вопроса, пришёл к выводу, что на пути любой методологии стоит 2 основных проблемы: Людям, занятым в проекте, как правило совершенно неинтересно изучать новую методику. Они вполне могут обойтись и без методологов, и при этом успешно создавать программное обеспечение. Проанализировав около сорока проектов из своей практики, автор сделал следующие важные выводы: Практически любую методологию можно с успехом применять в каком-нибудь проекте. Любая методология может привести к провалу проекта. Тяжеловесные методологии тоже могут успешно применяться в работе. Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией. Я не нашел ни одной теории, которая объяснила бы, почему облегченные методологии (те, в которых мало места уделяется всяческим формальностям), чаще приводят к успешному завершению проекта, нежели тяжелые методологии, где формальности играют очень большую роль. И тут я наконец-то понял, что прямо перед нами всегда находится нечто, чего мы не замечаем: люди. Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте. Теперь я рассматриваю все в обратном порядке - сначала люди, а потом методология, как второстепенный показатель. Какие же человеческие качества делают людей одновременно и столь важной, и столь непредсказуемой компонентой процесса разработки? Автор выделяет следующие: Человек - существо, которому необходимо общение. Причем общаться он предпочитает в режиме непосредственного диалога, лично, по типу "вопрос-ответ". Человеку трудно постоянно работать сверхурочно. Человек - существо изменчивое, он меняется в зависимости и от времени, и от пространства. Как правило, у человека есть чувство гражданского долга, он может хорошо ориентироваться в ситуации, брать инициативу в свои руки и делать "все, что необходимо" для того, чтобы проект завершился успешно. Человеку нужно время, как на размышление, так и на общение. Человек хорошо работает, опираясь на примеры. Человек предпочитает скорее потерпеть неудачу из-за своего консерватизма, нежели рискнуть, но сделать что-то необычным образом; ему больше нравиться изобретать, а не находить готовые решения, он может одновременно держать в голове совсем немного сведений, он делает ошибки и с трудом меняет привычки. Отдельная личность может легко возобладать над проектом. Способность человека выполнять те или иные задания в большей степени определяется его личными качествами. Когда я провожу опрос по какому-нибудь проекту, я всегда спрашиваю людей, что, по их мнению, привело к конечному успеху работы. Чаще всего я получаю один и тот же ответ: "В ключевой момент разработки несколько человек взяли на себя инициативу и сделали все от них зависящее, чтобы выполнить проект". Приведу ещё парочку важных на мой взгляд заключений, изложенных автором в статье:   - Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации".  - Вариации поведения культур методологу учитывать еще труднее, чем вариации каждодневного поведения отдельных индивидуумов. На сегодняшний день я не знаю ни одной методологии, при создании которой принимались бы во внимание культурные особенности (моя методология - не исключение). Впрочем, я знаю людей, которые учитывают местные культурные особенности при формулировании методологических рекомендаций. Конечно, я нисколько не тешу себя мыслью, что смог в этом коротком посте передать всю глубину и ценность изложеных в статье идей, однако надеюсь, что убедил многих в том, что статья достойна быть прочитанной.

Posted by Vitalii Tsybulnyk on Thursday, July 9, 2009 8:29 AM
Permalink | Comments (1) | Post RSSRSS comment feed

SCRUM в Microsoft.

Момент истины - барабанная дробь, и... Да, в Microsoft испльзуют SCRUM! Не уверен, что абсолютно для всех своих продуктов, но для большинства наверняка. Лично меня это обстоятельство весьма удивило, ведь я ещё помню времена появления и бурного продвижения "водопадно-спирального" MSF, когда достаточно уверенное владение MSF требовалось даже для весьма "попсового" сертификата MCSD. У меня ещё где-то валяются пару увесистых справочников по MSF, которые я планировал когда-нибудь заучить наизусть в качестве "идеального" процесса разработки, который испльзует "сам Microsoft!" Не судьба. Видимо ближайшее время этим справочникам место на свалке, как и любой идеологии, в которую уже не верят даже сами её создатели. Удалось пообщаться со старожилами Microsoft, которые ещё работали согдасно MSF, и работали надо признать весьма успешно. Однако после провала MSF в одном из крупных продуктов (как я понимаю, это был Windows Vista, выход которого был задержан на 2 года в том числе и по причине несовершенства процесса), Microsoft массово перешёл на SCRUM, где пребывает и по сей день. Тем не менее, искушённый читатель нверняка знает, что "провозгласить следование процессу SCRUM" и "следовать процессу SCRUM" - это, как говорят в Одессе, две большие разницы. Поэтому немного о том, как именно в Microsoft соблюдается SCRUM:  - работа над продуктом ведётся небольшими командами по 5-10 человек, в которых присутствуют представители 3-х ролей: Developer, QA, Program Manager.  - работа каждой команды над своей частью проекта разбита на небольшие промежутки времени, sprint'ы продолжительностью 20-30 дней, к концу каждого из которых выделенный "кусочек" функциональности доводится до необходимого уровня готовности, задаваемого в начале спринта.  - внутри каждой команды каждый день проводятся 15-тиминутные SCRUM митинги, задача которых - "держать руку на пульсе" спринта, а именно каждый участник спринта говорит о работе за последние 24 часа и на следующие 24 часа. Если возникают вопросы или есть почва для дискуссии, то назначается отдельный митинг, куда приглашаются только заинтересованные участники. Таким образом оперативно устраняются "блокировки" в работе и всегда можно проследить динамику протекания спринта, затраты времени на ежедневные митинги при этом минимальны.  - SCRUM соблюдается также и в том, что называется "атрибутами процесса", а именно в определённой форме документирования задач и их готовности, сбора метрик и т.п. Вы спросите: а как же тогда известные утверждения о том, что в Microsoft у всех всегда есть менеджер и любой сотрудник находится не дальше чем в 7-ми ступеньках от Стива Балмера? Это правда и в этом "изюминка" реализации SCRUM в Microsoft. Помимо SCRUM-команд, которые формируются динамически согласно требований продукта, и все участники которых выступают как равноправные individual contibutors, все сотрудники ещё входят в состав определённых "статических" команд, которые формируются по признаку специализации (может быть команда только developer'ов или только QA, никаких "смешений"). В этих "статических" командах роли уже распределяются в "классическом" иерархическом представлении: individual contibutor, senior individual contibutor, team manager (например developer - senior developer - development manager или QA - senior QA - QA manager). Состав этих команд меняется намного реже, т.к каждый участник такой "статической" комады может учавствовать в одной или нескольких (или ни одной) SCRUM-командах. Менеджер такой команды является непосредственным "начальником" для каждого члена команды, а у менеджеров команд есть в свою очередь свой "специализированный" (development или QA) менеджер продукта, а у тех - general manager продукта, что и представляет собой известную иерархию Microsoft.

Posted by Vitalii Tsybulnyk on Wednesday, January 21, 2009 11:13 AM
Permalink | Comments (8) | Post RSSRSS comment feed