Архив рубрики 'Управление большим числом задач'

Байка для оруженосца- 14. Сбалансированная производственная цепочка.

Суббота, Август 27th, 2016

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

Так что за огромным столом был традиционный для команды “five o’clock”. Но и на нем не обошлось без игр. Играли в игру из романа “Слишком много поваров” Рекса Стаута. Чеширский отобрал множество ингредиентов для заварки. Чабрец, липовый цвет, листья земляники … Всего дюжину добавок. И заварил пять огромных пузатых чайников. Но в каждый положил только десять компонентов. И теперь надо было угадать в каком чайнике чего не хватает. Организовалось две команды. Одной верховодила вернувшаяся с Байкала Соня, другой Шляпник. Королева и почтивший чаепитие свои вниманием Время были простыми участниками.

(more…)

Байка для оруженосца-7. Два вида списков задач.

Пятница, Май 13th, 2016

С самого начала рабочего дня Армигер скучал в чаепительной. За окном цвели яблони, а ему было нечего делать, и он составлял кроссворд на основании терминологии ISTQB. Кроме оруженосца в кухне был Чеширский, но он изучал какие-то документы. Но вот кухню омыла волна программистов во главе с Шляпником и Мартовским Зайцем.

- Хай.
- Привет.
- Доброе!
- Кому доброе, а кому и… - проворчал Оруженосец.
- Ничего. Придет время, и под твоей клавой навернется релиз-кандидат.

К чайникам выстроилась очередь. Программисты бурно обсуждали проблемы мержа.

В кухню вошел Черепах Квази. Шум стих.

- Представляете, захожу я сейчас в 42-ю, а там никого нет. Только Соня книгу читает, - сказал Квази, ни к кому конкретно не обращаясь.
- И что? - возмутился Шляпник. - Рекса Блэка надо читать.
- И больше там никого нет. Это все потому, что у вас тайм шитов нет.
- Ну да, а у вас есть. Только на наши релизы заказчик не ругается. Напомнить, что сказал ваш заказчик на ваш последний релиз?

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

Заказчик, в прошлом бандит, с сожалением констатировал, что времена изменились и что сейчас другие методы работы с организаторами подобных эксцессов. Но команду разработчиков попросил заменить. Во избежание.

На тушение пожара выдернули команду Королевы. В майские праздники. Вроде бы откат сделать не проблема. Но не проблема, только если инженеры соблюдают культуру разработки. Как говорится, тяжело править код за программистами, путающими бранч и транк. Да и релиз в пятницу вечером перед большими праздниками нарушал все мыслимые нормы безопасности. За два безумных дня команда Королевы много говорила о своих коллегах. Как подытожила Соня: “Если бы стены могли проявлять впитанные слова - в первый день они бы стали похожи на подъезд в Нижнем Тагиле, а на второй почернели бы полностью”.

- Но в чем-то он прав, - сказал Оруженосец. - Я с утра не слишком загружен.
Заяц и Шляпник переглянулись.
- Я сделаю сенчу. - Шляпник отправился к шкафам, а Заяц подсел за стол оруженосца.
- Сейчас я тебе объясню одну из ключевых концепций современной теории управления. Для начала разберем совершенно тривиальную производственную цепочку из одного рабочего центра. Проще уже некуда.
1654.PNG
- Разработчики работают по списку задач. И этот список может быть одного из двух типов. С недостатком задач или с избытком. Для первой линии техподдержки, админов и т.д. предпочтительным является список с недостачей. Для программистов, как правило, предпочтительным является список с избытком, но иногда применяют и список с недостачей. Например, если программист дежурит на техподдержке. Применение списка с недостачей означает, что разработчики обязаны часть времени простаивать. Обязаны! Если не простаивают - надо вызывать на ковер менеджера. Список с избытком означает, что часть задач обязана быть не сделана. Если делаются все задачи, опять же, нужно разбираться в проблемах управления. Представь, что мощность отдела программистов 100 единиц продукции в неделю. Для списка с недостачей рекомендуется, чтобы входящий поток заказов был в 70-80 единиц. Т.е. разработчики должны простаивать порядка 25% времени. Если используется список с избытком, то входящий поток должен быть отрегулирован на 130 - 200 единиц. Примерно вот так:
2654.PNG

Зеленые зоны - это хорошо настроенный поток. А красная - плохо.

- А если все-таки сделать сбалансированный поток?
- Если его попробовать сделать, то будет как у Квази. К счастью, сбалансированные цепочки встречаются редко.
- Сложно настроить?
- Нет, - подключился Кот, - настоящая причина того, что сбалансированные цепочки встречаются редко, намного более фундаментальна. Дело в том, что чем ближе ты к состоянию идеального баланса, тем ближе ты к банкротству.
- Хорошо, предположим. В дальнейшем я хотел бы увидеть модель, но сейчас я поверю опыту Чеширского Кота. - согласился Оруженосец. - И как настроено у нас?

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

- Ага, - Шляпник поставил чайник с сенчей на стол, - среднестатистический менеджер приходит в истерику, услышав о современных методах управления. У него пропадает аппетит, начинается изжога, и в общении он становится крайне неприятен.
- Все верно, коллеги. - К их столу подошел Чеширский Кот. - А тебе, юноша, необходимо как можно быстрее ознакомиться с современными методами управления и перестать комплексовать по поводу своих простоев. А то так и до нервного срыва недалеко.

- Ладно, камрады, по коням. К вечеру сделаем финальный мердж и отдадим билд на тестирование. А ты пока кроссворд закончи.
- А с таймшитами то что?
- А про них в следующий раз.
- А матмодель?
- А матмодель сбалансированной цепочки посмотри в блоге Макса Крамаренко.

Защита от впихивыния невпихуемого

Понедельник, Март 21st, 2016

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

Для предотвращения впихивания невпихуемого есть довольно простые правила.

1. Гениальная идея до того, как попасть к разработчику должна быть записана в трекер. Самим креативщиком.

Невыдуманная история. В одной из фирм маркетологам запретили чисто устную постановку задачи. Сначала трекер. Только потом можно рассказать устно. Поток гениальности снизился вдвое.

“Если ты не можешь записать идею на родном языке - возможно, тебе рано о ней рассказывать?”

2. Еще до фазы управления идея должна пройти минимальный анализ.

Иногда все очевидно и анализ не записывается. Пример: “Под нового заказчика ООО “Атлант” сделайте новый проект в Jira & пространство в Confluence”. Потому как в регламенте написано про НДА, которое реализуется через разграничение прав доступа к проектам Jira и пространствам Confluence. Но под “поток гениальности” анализ нужно зафиксировать.

3. Перед тем как разработчик хотя бы узнает о задаче порожденной гениальной идеей, идея должна пройти фазу управления.

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

Для случая непрерывной поставки и ограничения находящемся в производстве третье правило трансформируется в регламент со следующими пунктами:

1) Представитель заказчика утверждает порядок очереди работ. Т.е. основное управление осуществляется через “очередь” работ. Чем выше в списке (”ближе к кассе”), тем раньше задачу начнут делать. и вот этот самый порядок в очереди утверждается на встрече представителей заказчика и исполнителя. А если заказчик адекватный, то функции управления очередью можно отдать ему полностью и сэкономить на зарплате менеджера в группе разработки.

2) Задача прожившая в очереди работ более определенного времени (подбирается на основании экспериментальных данных) закрывается автоматически (скриптом). Другой вариант - должна быть не длиннее чем N задач. Например, если в неделю сыплется 10-20, а делается 5-10 задач. То у 50-й задачи нет шансов быть сделанной. За те 6-9 недель, которые нужны, чтобы до нее добраться прилетит еще 100-130 задач. И, если хотя бы половина из них будет поставлена перед 50-й, то…

3) Задачи управляемые по датам (изменение порядка исчисления НДС с 1.04.года) висят в очереди как можно дольше, пропуская вперед все задачи с немедленным экономическим эффектом. Смысл в том, что задачи, управляемые по датам приносят экономический эффект только после наступления этой даты. И для максимизации прибыли фирмы нужно откладывать их на последний момент. Но, естественно оставляя запас по времени под различные риски.

Тонкий момент. Для простоты, пусть у нас будет процесс, без проектов. В этом случае управление осуществляется регламентом. По пунктам:

* Менеджер не имеет права отдавать указания исполнителям. Исполнителями управляет регламент работ.

* Менеджер обязан управлять очередью. Не управление очередью со стороны менеджера должно рассматриваться как неисполнение прямых служебных обязанностей со всеми вытекающими последствиями.

* Менеджер (не обязательно этот же) может поменять регламент.

——–

Приложение. Дополнения, разъяснения и предупреждения.

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

Для справки. Фирма Хитачи несколько раз пыталась у себя производственную систему Тойота. У них хватало и опытных наставников из Тойота и денег и упорства. Но их производственная среда отличалась от среды Тойота. Итого: потеряв кучу денег они не смогли внедрить производственную систему Тойота и были вынуждены разработать другое прикладное решение под свою среду.

Вот небольшой список вопросов для определения, какое прикладное решение вам подойдет:

* Заказчик. Внутренний / внешний?

* Процесс или проект?

* Какова цена бага пропущенного в продакшен?

* Где находится ограничение системы?

* Сколько рабочих центров задействовано в работе?

* Взаимозаменяемы ли разработчики?

Это не все вопросы, но пока этого достаточно.

Для случая рассмотренного выше, ответы на вопросы будут следующие:

1. Заказчик внутренний. Упрощается взаимодействие. Не нужно «Закрывать контракты».

2. Процесс. Это означает, что задачи слабосвязаны и могут решаться независимо.

3. Цена бага незначительна по сравнению с преимуществом быстрого выпуска.

4. Ограничение системы находится в разработке. Пусть это сделали сознательно. Численность программистов сознательно поддерживается на таком уровне, чтобы гарантированно не быть в состоянии делать примерно половину задач. Сделано это, чтобы софт не превращался в ералаш (смотри «Слон живописец»).

5. Данный рабочий центр практически не взаимодействует с другими в потоке создания ценности. Т.е. когда заказчик размещает заказ, этот центр разработки все делает сам без привлечения программистов, тестировщиков, аналитиков из других отделов.

6. Разработчики взаимозаменяемы.

Вариант использования как элемент планирования

Воскресенье, Ноябрь 8th, 2015

Use Case (вариант использования, ВИ, Прецедент, юскейс) это один из вариантов записи требований к системе. Дополнительную информацию о них можно узнать из статей:
•    Что такое Use Case и зачем они нужны?
•    Пример требований к системе
•    Байка для оруженосца-5. Использование вариантов использования.
•    Примеры вариантов использования (Usecase)
В отличие от многих других способов записи требований юскейсы обладают двумя приятными особенностями:

•    Существует множество формальных способов проверки реестра юскейсов на полноту.
•    Описан способ, как выделить уровни юскейсов.

Эти особенности позволяют легко создать достаточно полный реестр атомарных задач. Термин «Уровень» был предложен Алистером Коберном. Если очень грубо, то:

  • Юскейс «уровня моря» - это юскейс, при котором время взаимодействия с системой не превышает 20 минут и который, будучи выполнен многократно, приносит пользу. Часто юскейсы этого уровня составляют основу спецификации требований.
  • Юскейс «выше уровня моря» (змей, облако) - более высокоуровневый. Содержит несколько юскейсов уровнем ниже. Часто служит основой для переговоров с заказчиками.
  • «Ниже уровня моря» (рыба, моллюск) - составная часть «уровня моря». Часто используется для описания взаимодействия между системами в рамках одного юскейса уровня моря.

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

Рассмотрим несколько разных проектов.

Проект А.
Маленький проект. Несколько недель (месяцев) для одного программиста.
Спецификация требований на основе ВИ на него можно найти по ссылке: «Пример требований к системе»
Примечание. Сегодня я бы написал документ по-другому, но и такой вариант довольно сильно облегчит жизнь программисту.

Это несколько недель для одного программиста. Сколько именно, зависит от платформы.
1.    Java / C# + MSSQL – 6-12 недель
2.    Дельфи + SQLite – раза в два меньше
3.    FileMaker / MS Access / FoxPro / Clipper / Paradox – 3-10 дней

Если мы выбираем в качестве платформы C# + MSSQL, то для этого проекта удобно использовать юскейсы «уровня моря» в качестве уровня атомарной задачи. Реестр задач по этому проекту мог бы выглядеть следующим образом:

  • Работа с «Партнерами» - (юскейс над уровнем моря)
    • Создание необходимых структур в БД - (не юскейс)
    • Просмотр списка партнеров - (юскейс уровня моря)
    • Создание «Партнера» - (юскейс уровня моря)
    • Просмотр «Партнера» - (юскейс уровня моря)
    • Изменение «Партнера» - (юскейс уровня моря)
    • Удаление «Партнера» - (юскейс уровня моря)

Программисты на платформе C# + MSSQL, с которыми мы общались, утверждали, что делают в неделю 2-10 юскейсов вида «Просмотр, создание, изменение». То, что надо. Проводить дальнейшую декомпозицию нужно в очень редких случаях.

Примечание. При программировании на Paradox «Уровень моря» становится слишком мелок. Впрочем, с Paradox весь проект становится совсем крошечным, и для него формальный реестр задач необязателен.

Проект Б. Проект среднего размера. Несколько человеколет (десятков человеколет).
Создание интернет-магазина для крупной розничной сети.
Руководство уделяет пристальное внимание дизайну страниц, и поэтому создание макета, дизайн, верстку и программирование выполняют разные люди. Кроме того, в ходе выполнения одного единственного юскейса уровня моря может понадобиться несколько страниц. Нужен уровень помельче.
Реестр задач:

  • Работа с Заказом
    • Просмотр заказа
      • Макет
      • Дизайн
      • Верстка
      • Программирование
    • Оформление заказа для авторизованного покупателя
    • Оформление заказа для неавторизованного покупателя
      • Страница «Вход»
        • Макет (не менее 6)
        • Дизайн макета 2
        • Дизайн макета 4
        • Дизайн макета 5
        • Верстка утвержденного макета
        • Программирование
      • Страница 2
      • Страница 3
      • Последняя страница
        • Макет
        • Передача заказа в программу логистики (юскейс)
        • Расчет бонусов (юскейс)

В данном случае юскейсы, в первую очередь, является группирующей сущностью атомарных задач. Что касается, атомарных задач, то это, как правило, будут не юскейсы. Но иногда будут встречаться юскейсы уровня рыбы и моллюска.

Измерение трудоемкости атомарной задачи

Суббота, Ноябрь 7th, 2015

Оценка трудоемкости задач имеет негативный эффект. Но как иначе определить, что задача достаточно мелка и ее дальнейшая декомпозиция не требуется? Налицо управленческий конфликт. Нарисуем «грозовую тучу».

aiciaay-ooa-ioaiee-odhoaiaieinoe.png
Как ее разбить?

А зачем нам оценивать трудоемкость, если мы можем ее измерить на основании исторических данных? Возьмем для примера работу верстальщика за предыдущие периоды, сгруппированнуе по 4 недели. Предположим, мы получили следующую статистику:

  • 1-й период - 37 страниц
  • 2-й - 46
  • 3-й - 42
  • 4-й - 30
  • 5-й - 51

Это означает, что:

  • В среднем одна страница меньше двух дней. Причем существенно меньше.
  • На больших объемах происходит усреднение, и это позволяет управлять версткой на основании статистических данных. Мы можем с очень высокой точностью сказать, когда будут сверстаны все 800 страниц. Примерно за 80 недель. Процесс разработки переведен в статистически управляемое состояние.

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

Несколько тонких моментов.

  1. Трудоемкость надо считать как N задач в M дней (800 задач в 400 дней), а не одна задача в среднем 2 часа. Ваш сотрудник ходит на совещания, читает почту, вынужден писать вам отчеты и т.д. Но это совершенно не важно. Заказчика волнует «Когда закончится проект?».
  2. Список сделанных атомарных задач является отличным отчетом. Другой отчет для контроля за работой сотрудника не нужен. Бонус: «Хотите поднять производительность сотрудника на 5-10%? Отмените таймшиты. Используйте реестр задач как отчет.»
  3. Обязательно возникнет вопрос: «Да, но есть страницы, которые верстались по неделе и более. Их надо разбить!». Нет, не надо. Пока отклонение в трехсигмовом пределе, не надо насиловать процесс. Будет только хуже. Смотри главы 4, 5, 6 книги «Пространство доктора Деминга».
  4. Пожалуй, самое главное. Вычисление уровня и создание реестра атомарных задач обязательно – обязательно! – должны предшествовать попыткам управлять задачами по «приоритетам», «дедлайнам» и т.д. Практически все пытаются сделать наоборот, что приводит к дичайшему хаосу в управлении. Вернее, к отсутствию управления.

Оценка трудоемкости атомарной задачи

Суббота, Ноябрь 7th, 2015

Дисклеймер

Для понимания статьи крайне желательно знание современных теорий управления. В первую очередь теории ограничений Голдратта.

Я могу быть не прав. Если эксперименты покажут, что я не прав, я это приму.
Проблематика

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

Требования:

  • Оценка трудоемкости должна приносить пользу. Т.е. улучшать производственный поток.
  • Оценка трудоемкости не должна приносить вреда. Или вред должен быть меньше, чем польза.
  • Оценка трудоемкости должна быть возможной. Если погрешность оценки более 100%, то, может быть, не стоит и давать оценку?

Если вы с этим не согласны, то далее статью можно не читать.

Рисуем фон

Как можно использовать оценку трудоемкости? Или «Какую пользу это принесет?» Будем исходить из того, что наш заказчик умеет считать деньги.

Оценка трудоемкости должна приносить пользу

Для внешнего заказчика важны сроки и цена. Трудоемкость не имеет значения. Нормальный заказчик, заказывая в интернет-магазине стиральную машинку, не спрашивает, сколько часов было потрачено на ее изготовление. Его интересует «когда привезете?» и «сколько стоит?». Но при разработке софта на заказчиков иногда находит помутнение. Рассмотрим два варианта:

  1. срок поставки – неделя, трудоемкость один час, выставленная цена - $10000
  2. срок поставки – две недели, трудоемкость пятьсот часов, выставленная цена - $50000

Существуют менеджеры, которые выберут второй вариант . Но мне интересней иметь дело с теми, кто выбирает первый.

Для внешнего заказчика польза от оценки трудоемкости нулевая.

Для внутреннего заказчика ценность также нулевая. В разработке ПО (как и в любом другом бизнесе) есть только два варианта с размещением ограничения системы. Ограничение системы может быть или внутри производства, или вне. Если вне, то бизнес не беспокоит, какова трудоемкость атомарной задачи - полчаса или два дня. Но может беспокоить, будет ли выведен хотфикс через час или через неделю. Сроки важнее. Для фичи иногда ситуация другая. Там может быть расчет по ROI . Если же ограничение внутри производства, срок выхода задачи в релиз определяется исключительно местом в очереди задач. Совершенно не важно, какая трудоемкость: полчаса или день. Если впереди сотня других задач, то срок выпуска – ориентировочно полгода. По имеющимся у меня статистическим данным, снятым с нескольких фирм: «Эффективность жизненного цикла атомарной задачи, при условии нахождения ограничения внутри разработки ПО, составляет порядка 1%. Это означает, что атомарная задача трудоемкостью в один день будет сделана в среднем через 100 рабочих дней. Но календарное время выпуска можно менять, изменяя очередность в очереди задач». Смотри «Историю одной доски» от Макса Дорофеева.

Польза от оценки трудоемкости нулевая.

Оценка трудоемкости не должна приносить вреда

Сам факт наличия оценки трудоемкости приводит к уменьшению производительности программиста. Исследования Лоуренса и Джеффи от 1985 года (Jeffry, D.R. and M) показали, что производительность падает в полтора – два раза. Смотри книгу «Peopleware». Теоретические выкладки Голдратта в книге «Критическая цепь» это подтверждают. Теоретический расчет Голдратта соответствует  полученным экспериментальным результатам.

Оценка трудоемкости приносит вред.
Оценка трудоемкости должна быть возможной

Несколько лет назад я проводил эксперимент по разбросу трудоемкости типовой атомарной задачи сам. Не «rocket science». Обычной стандартной задачи. Такие задачи программисты решают сотнями. И да, я не предупреждал участников, что я измеряю. Смотри «двойная слепая выборка».

Результат удивил даже меня. Фактический результат показал, что в зависимости от того:

  • выпил ли программист кофе до или после решения задачи,
  • встал с левой или правой ноги,
  • прогулялся после чтения условия или нет,
  • начал с клавиатуры или с мыши

фактическая трудоемкость отличается. Примерно в пятнадцать раз. На одну и ту же стандартную задачу программист может потратить 15 минут. А может полдня. А может час. Фактической трудоемкости. Без учета перекуров и прерываний. Фактической трудоемкости! С прерываниями разница может быть и большей. Т.е. общая причина вариации (термин Шухарта) делает невозможной оценку трудоемкости атомарной задачи.

Примечание. Справедливости ради надо упомянуть еще об особой причине вариаций оценки трудоемкости. Смотри исследование «Ошибка планирования» от 1994 года. Но особую ошибку хотя бы компенсировать можно. А вот попытка компенсации общей причины приводит только к ухудшению ситуации. Смотри пятую главу книги «Пространство доктора Деминга» Генри Нива.

Итог
Оценка трудоемкости атомарной задачи:

  • не приносит пользы с точки зрения определения срока выпуска
  • ухудшает производительность
  • невозможна

Вы можете поставить под сомнение результаты экспериментов. Это нормально. Поставьте свои.

И что делать?

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

Понятие атомарной задачи, часть 2

Понедельник, Ноябрь 2nd, 2015

Рекомендуемые правила для атомарной задачи

1. У атомарной задачи не может быть более одного исполнителя.

2. Атомарная задача должна вносить изменения не более чем в одну программную систему.

3. Длительность атомарной задачи – не более двух дней.

Одна задача – один исполнитель.

Нам нужно реализовать страницу «один клик» в рамках разрабатываемого сайта. Задача разбивается на подзадачи:

а) Концепт (дизайн, прототип) интерфейса. Исполнитель - проектировщик интерфейса.
б) Отрисовка интерфейса. Исполнитель – дизайнер (художник/оформитель).
в) Верстка. Исполнитель - верстальщик.
г) Программирование - программист.

Зачем это надо? Предположим, фиксируются только “фичи”. Напрмер, “Один клик”. Руководитель проекта уехал в отпуск в Гималаи, где нет сотовой связи. Верстальщик живет в Минске и заболел ангиной. Кто из отдела в 30 человек программистов отвечает за программирование конкретно этой страницы, в реестре не указано, а отдел программирования частью расположен в Москве, частью в Твери и частью еще в 6 городах. И интернет-магазин - не единственная задача, которой они занимаются. А оформитель ушла в декрет и из 70 висевших на ней задач передала не все. И передала их четырем другим оформителям. Внимание, вопрос. Как заказчику оперативно узнать, выйдет ли «один клик» в двенадцатом релизе? Поэтому: одна атомарная задача - не более одного исполнителя. Именно так она должна быть внесена в реестр задач. “Один клик” декомпозировать и декомпозировать.

Одна задача – одна система

Так удобней управлять версиями. Для каждой задачи, связанной с изменением кода, желательно указывать релиз, в котором планируется выпустить, и релиз, в котором задача сделана.

Приведу конкретный пример. Пусть внешний заказчик заказал нам три фичи «А», «Б», «В». Заказчик умный и платит не за трудоемкость, а за свой профит. Цены:

•    «А» - $100k,
•    «Б» - $20k,
•    «В» - $10k.

Трудоемкость у них примерно одинаковая, и в нашем продукте «К» мы делаем по одной фиче в релиз. С точки зрения ROI выгодно запустить сначала вичу «А». Но для фичи «А» нужно еще в другом продукте «Л», который разрабатывает другая команда, кое-что подкрутить. Обе команды выпускают релиз раз в месяц.

Мы сейчас планируем сентябрьский релиз, а команда продукта «Л» запланировала работы по фиче «А» на ноябрьский релиз.
Оптимальным при этом будет сделать в сентябре фичу «Б», а «А» запланировать на ноябрь.

Но, не выполнив декомпозицию до «одна задача – не более одной системы», будет сложно «на лету» делать такое планирование. И на моей практике отсутствие такой декомпозиции  достаточно серьезно выбивало проект из сроков.
Атомарная задача – не более двух дней.

Эту идею я изначально нашел в статье Джоэла Спольски «Планирование программного обеспечения малой кровью», и впоследствии находил ей множество подтверждений. Человеку проще оперировать задачами, размер которых измеряется в часах. Проще держать в голове ее целиком. При оценке 2 – 16 часов ошибка оценки предположительно минимальна. Статья-гипотеза «Реальная оценка, или почему наступают дедлайны?» Кроме того, если атомарные задачи по факту окажутся в среднем четырехдневными, то вы успеете оперативно скорректировать планы. Таким образом, очень удобно отслеживать прогресс работ по фиче. При условии, что в среднем в один день верстается одна-две страницы, то после того, как вы составили реестр всех страниц – вы получили управляемый процесс верстки. Одна страница и будет для верстальщика одной атомарной задачей.

Через фичи удобно вести управление требованиями. Без реестра атомарных задач невозможно нормальное управление разработкой ПО. Впрочем, вы можете не захотеть управлять.

«Меняться необязательно. Выживание – дело добровольное» © Э. Деминг

Понятие атомарной задачи, часть 1

Понедельник, Ноябрь 2nd, 2015

Дисклеймер

Я не могу научить управлять разработкой ПО в одной статье.

Я не могу дать все определения в одной статье. Голдратт для определения понятия «Критическая цепь» написал книгу. Генри Нив для определения понятия «Операционные определения» и для описания их важности написал главу книги.

Также я не уверен, что одних статей достаточно. Возможно, нужны тренинги.

В любом случае ждите другие статьи.

Статью следует рассматривать совместно с теорией ограничений и работ Деминга, из которых и взяты специальные термины.

Аудитория статьи – в первую очередь операционный менеджмент.

Проблематика

От менеджеров часто приходится слышать:

  • А почему так дорого?
  • А почему так долго?
  • А почему, если фактическая трудоемкость всего 60 часов, выпустили только через три месяца? Другая команда в другом продукте должна была внести изменения и внесла только сейчас? Почему я узнаю об этом только сейчас?

И, конечно же, одно из самых популярных: «У нас ни один проект не завершается в расчетный срок. Планировать не умеете?»

Некоторые операционные определения и ограничения статьи

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

На текущий момент практически стандартом де-факто стали следующие положения:

  • Есть два типа задач. Разработка новой функциональности и исправление ошибок.
  • Обобщающий термин - запрос на изменение (ЗНИ).

В этой статье рассмотрим задачи по разработке новой функциональности. Введем дополнительное понятие «фича». «Фича» - это набор свойств, которые, будучи реализованы, приносят значимую пользу бизнесу, которую можно выразить деньгами. Есть некий минимальный набор свойств фичи, без которого выпускать релиз нет смысла. Потому что это не приносит бизнесу пользу. В качестве примера рассмотрим интернет-магазин. Вряд ли имеет смысл выпускать функционал оплаты в интернет- магазине, если не реализован функционал оформления заказа. Понятие фичи очень размыто, поэтому давайте пока примем, что интернет-магазин может содержать множество фич, среди которых мы выделим:

1.    Найти товар.
2.    Просмотреть свойства товара.
3.    Купить.

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

Фичи это то, по поводу чего удобно договариваться с заказчиком. В одном случае вы услышите: «Какая корзина? У нас розничная торговля холодильниками. Не покупают люди пять холодильников сразу. Сначала делайте один клик. Через полгода, может быть, вернемся к идее корзины». Может быть и обратная картина: «Мы книгами торгуем. Не будет человек одну книгу за 200 рублей заказывать при стоимости доставки заказа в 300 рублей. Сначала корзина».

Декомпозиция и суперпозиция фич отдельная большая тема, а пока вернемся к атомарной задаче. Возьмем фичу «купить в один клик». В среднем и большом бизнесе (оборот сети магазинов - сотни миллионов долларов и выше) этот самый бизнес обслуживают десятки и сотни систем, взаимодействующих друг с другом. Если брать «М-Видео», то у них очень значимый сегмент (более 10%) - торговля через интернет. Но такие фичи интернет-магазина, как, например, программа «постоянный покупатель» (накопление и трата бонусов) должна быть общей и для онлайна и для оффлайна. Скорее всего, это не часть интернет-магазина и не часть оффлайн -магазина, а отдельный программный продукт. Фича «один клик» может потребовать внесения в несколько систем, работы множества программистов (в том числе из разных команд, а иногда и из разных фирм), а также верстальщика, оформителя и т.д. И трудозатраты на нее получаются немалые. Заказчика интересует прогресс и прогнозируемая дата выпуска. И одной большой задачи для координации множества людей, тем более из разных отделов и/или фирм, оказывается недостаточно.

Если одной задачи для координации недостаточно, нужно несколько задач. Нам нужен реестр задач, который позволит:

  • Оценить трудоемкость исполнения фичи и проекта в целом. Главное – проекта в целом.
  • Оценить календарное время исполнения фичи и проекта в целом.
  • Перевести разработку ПО в статистически управляемое состояние.
  • Сократить время проекта за счет работы по «Критической цепи».

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

В моей практике есть примеры:

  • Введение реестра атомарных задач позволяло рассчитать время проекта с точностью до 5-10%. Неплохо?
  • Введение реестра атомарных задач позволяло сократить время проекта.
  • Введение реестра атомарных задач позволяло уменьшить напряженность в отношениях заказчик – исполнитель.

Управление большим числом задач в проектах по разработке программного обеспечения - 0

Четверг, Сентябрь 24th, 2015

А что значит большим? Или как спрашивала мартышка из “38 попугаев”: что такое куча? Вот десять - это куча? И отличается ли управление большим числом мелких задач от управления малым числом больших задач? А большая задача это сколько? Есть масса вопросов. Но если постоянно не задавать эти вопросы и не отвечать на них, то будут получаться мертворожденные схемы, которые работают только в теории.

В теории между теоррией и практикой нет никакой разницы. На практике же разница огромна.

Столяр пользуется множеством инструментов. Он не пытается закручивать гвозди рубанком. И не пытается вырезать пазы шурупом. Чем мы хуже? Почему мы пытаемся применить SCRUM там, где он не применим? Управление разработкой ПО - это огромная мозаика. Ее можно складывать сразу из нескольких мест и совсем не обязтельно слева направо. Науку управления не обязательно учить по схеме PMBoK. В любом случае одну и ту же тему придется пройти несколько раз, рассматривая ее с разных аспектов.

ГОСТ 34.603 (виды испытаний автоматизированных систем) вполне применим. В определенных ситуациях. И ГОСТ 9126 (характеристики качества и руководства по их применению) тоже применим. В других ситуацих. Но есть ещ и третья ситуация, когда отличным вариантом будет не XP или RUP, а ГОСТ Р 50779.42 (контрольные карты Шухарта) от 99 года.

Я попробую разложить свой опыт на цикл статей, в каждой из которых осветить маленький аспект управления. Управления не обязательно проектами. Возможно, управления процессами. Или НИР-ами. Короче, разработкой ПО.

Багтрэкинг, работа с ним или без него

Понедельник, Декабрь 22nd, 2014

Не исключительно мое мнение:
Основное назначение трекера - дать возможность руководителю работ управлять реестром работ по проекту. Реестр задач на исправление багов,  подмножество реестра работ по проекту.”

Рекомендуемая последовательность:

  1. Внедряем процесс ведения реестра.
  2. Внедряем процесс управления реестром.
  3. Внедряем процессы создания развернутых описаний элементов реестра.

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

“Если руководитель на регулярной основе не занимается управлением реестра, то с управлением проблемы”. И, очень вероятно, бактрекер не нужен. Если вы не собираетесь делать шаг “2″, то зачем вам шаг “1″!?
Кстати. “Внедрение процесса управления реестром” дает огромный эффект. Вполне может получиться, проект по разработке системы удастся сделать в 1.5 - 2 (это не только моя оценка) раза быстрее.