Разговоры про ускорение разработки программного обеспечения ведутся уже много лет. Насколько ожидания оправданы? Можно ли ускориться, и как сильно? И главное — что для этого нужно?
С какими возможными проблемами столкнутся современные производители программного обеспечения при оценке, разработке стратегии и составлении дорожной карты будущего с использованием известных моделей зрелости.
Недавно на одной из внутренних тусовок, где обсуждали Канбан для продуктовых команд, мимоходом была озвучена мысль о том, что коэффициент эффективности потока нынче уже не в моде, поскольку не учитывает задачи, зависшие в производственной системе.Попробую возразить. Для того, чтобы это сделать, стоит напомнить, что это за метрика, и сделать пару уточняющих охват заметки замечаний. Коэффициент эффективности потока (FE) показывает какую долю времени, проведённого задачей (work item) в производственной системе (т.е. lead time, LT), задача действительно обрабатывалась (т.е. велась работа над её решением). Если просуммировать это «чистое» время обработки мы получим так называемое время обработки — process time (PT, aka touch...
Одной из наиболее эффективных стратегий, приводящих горе-руководителей к провалу, является концепция неограниченной незавершённой работы. Отсутствие лимитов на задачи «в работе» (Work in Progress) легко оправдывается необходимостью «эффективно использовать ресурсы», «делать больше» чтобы недопустить «слив актива». Все знают, что величайшее преступление — позволить кому-либо сидеть без дела и «расслабляться» при загрузке менее 125%. Большинство гибких/бережливых/модных/цифровых трансформаций подвигают организации создавать ценность самого высокого качества с наименьшими затратами времени. Это непростые цели, требующие реальных изменений при сосредоточенной поддержке руководства. Проблема с этими целями заключается в том, что трудно оценить, насколько вы к ним продвинулись, улучшилась ли организация или нет. Чтобы случайно не допустить...
Приглашаем Вас на бесплатный вебинар 16 декабря в 11:00 «Продуктовый подход в ИТ. Почему у вас не получится».
Тема этого вебинара возникла неспроста. Всё больше и больше компаний задумываются о продуктовом подходе. Некоторые уже идут в этом направлении. Определяют продукты, выделяют продуктовые команды.
Есть несколько вопросов, которые мне задают практически каждый день. Сколько данных нам нужно для надежного прогнозирования доставки? Что делать, если у нас нет исторических данных? Что если у нас много данных, но мы им не доверяем? Как выбрать «скользящее окно» данных для прогнозирования доставки?
Открыта регистрация на осенне-зимний сезон 2021 бесплатных вебинаров CleverTALK. Осенне-зимний сезон 2021 бесплатных вебинаров CleverTALK начнётся уже 18 ноября. В программе этого сезона три вебинара.
Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки, сколько заявок приходит от какого филиала, сколько распределяется на какого специалиста поддержки, что чаще всего ломается и требует внимания. Понять объективно, а не в ощущениях. И понимать регулярно. Нет, я не помешан на метриках и отчётах. Знаю много случаев, когда управленческие решения принимаются вовсе без данных, и оно срабатывает. Что уж там говорить, с 2009 года, когда появился Cleverics, мы в нашей компании принимаем сотни решений каждый год,...
Рассмотрим простейший поток создания ценности: На ваш взгляд, что в этом потоке не так? Подумайте, и когда будете готовы — листайте ниже. Ответ бросается в глаза — один из шагов отличается от других. Опциональный шаг «Отложено» подразумевает, что задача, двигающаяся по потоку, может встать на паузу после этапа «В работе», но до этапа «Проверка». Причины этой паузы из схемы не ясны, но шаг «Отложено» даже визуально, из-за подписи «(опционально)», уже выглядит инородным. Однако проблема не в инородности. Проблема в том, что на схеме изображён не поток создания ценности, а что-то иное: бизнес-процесс,...
Гибкие методологии управления ИТ-разработкой изначально несли в себе посыл становится клиентоориентированными, фокусироваться на бизнес-ценности, чтобы создавать результат, максимально удовлетворяющий заказчика. Двадцать лет назад мысль о том, что ответственность ИТ-разработчиков заключается не просто в создании новой функциональности, а в поставке ценности была действительно революционной. Фокусировка на ценности позволяет найти лучшее техническое решение из множества доступных разработчикам, когда они выбирают способ реализации требование бизнеса. В итоге результат соответствует ожиданиям заказчиков и созданную функциональность не приходится дорабатывать или переделывать. Что экономит время разработки и повышает качество продукта. Однако, с течением времени стало понятно, что фокусировка разработчиков на бизнес-ценности задач штука совершенно необходимая, но...
Неоднократно упоминавшийся на нашем портале Чарльз Бетц (Charles Betz, среди прочего автор «Digital Practitioner Body of Knowledge (DPBoK)», являющейся базой для соответствующей сертификации от The Open Group, консорциума, разработавшего TOGAF, IT4IT, к которым, кстати, Чарльз тоже приложил руку) опубликовал на прошедшей неделе любопытный фрагмент своей беседы с Agile-классиком Доном Райнерстеном (Don Reinertsen). Дон — автор книг «Разработка продуктов за половину времени» («Developing Products in Half the Time»), «Управление дизайн-фабрикой» («Managing the Design Factory»), «Принципы потока продуктовой разработки» («The Principles of Product Development Flow: Second Generation Lean Product Development»). В интервью эксперты рассуждают о недостатке автономных (читай «продуктовых») команд – сложности накопления...