Как стать автором
Обновить

Комментарии 7

Алексей, скажите, пожалуйста, есть ли у вас опыт участия в реальном проекте по разработке ПО? В т.ч. с использованием тех методологий, которые вы упомянули в статье.
День добрый, да с 90х по конец 2000х в основном организация производства софта по классике — с необходимостью перехода в итерации.
Все в статье очень хорошо. Одно но — вывод — на мой взгляд, переход к примеру с конвейером Форда, не очень уместный. Разработка ПО имеет существенное отличие от материального производства — разово разработанное программное обеспечение почти не требует затрат на тиражирование. Но зачастую имеет существенные затраты на внедрение — которые фактически отсутствуют у результатов конвейерного производства, например автомобилей. С другой стороны конвейер ориентирован на разовые, повторяющие операции, инженерные задачи, существенно отличаются от них.
Поэтому указанная инновационная модель в виде конвейера — на мой взгляд, все та же модель agile в виде последовательности спринтов, в которой каждому сотруднику дают задачи под его специализацию на весь объем спринта. Т.к. в методологии agile разработки — вовсе нет жесткого требования кустарного/мануфактурного производства всей командой всех видов работ. Да и редко какой разработчик сядет на аналитку, или там инженерную инфраструктуру. По моей практике — в более менее крупных командах (от 5ти человек) — есть эти специализации и они разделены между сотрудниками. Все простои решаются двумя смежными специализациями у сотрудников и периодизацией задач по году. Например у ИТ работающем в гос.секторе январь-февраль время доделки хвостов, март-июнь время продаж и разработки «новых продуктов», июль-ноябрь основной проектной реализации, декабрь — авральных допилов ключевой функциональности под требования закрытия контрактов + модель переработок с двойной компенсацией времени — достаточно мотивирующая и позволяет не набирать избыток специалистов, а работать всегда на неком «дефиците», чему кстати и дефицит ИТ-специалистов способствует.
У всех остальных — маржинальность разработки в ИТ отрасли пока такова, что можно направлять простаивающих сотрудников на «перспективные свои проекты», на устранение технического долга, переделку архитектуры и платформы, «новые продукты» и т.д. и т.п.
При этом дефицит ИТ-шников способствует высоким окладам и у них смещается модель мотивации в сторону «интересной, развивающей и разнообразной» работы, а это явно противоречит принципам конвейера.

День добрый!


Тут есть два момента организационный и философский.
Философский очень хорошо описан у Анчарова:


Главное правило для художника — быть исключением. Хочешь, не хочешь. Такая промышленность.
Потому что, если я два велосипеда сделаю вместо одного, то это будет — два велосипеда. А если я два раза один и тот же стих напишу, то это будет один стих, а не два. Стих или картину, любое сочинение — все равно. А сколько раз я эту картину изготовлю, сколько штук я этого сочинения изготовлю — это уже значения не имеет. Это называется тираж. Тираж, повторение, репродукция — это есть ремесло. А искусство каждый раз происходит по одному разу.
Вот в чем особенность, дорогой дядя.

В общем с этим нельзя не согласиться, что разработчик пишет однократно, но


  • ПО всё ж таки продаётся по модели тиража, а не однократно, т.е. мы либо платим за лицензию, либо аредуем её(оптимизируя налогообложение)
  • Производство искусства в отличие от производства ПО не формирует крупных контор, типа MS, по разработке и производству картин (иначе тираж), единственное — модные дома, но и там тираж и деньги.

Организационный — здесь в отличии от agile идея в том, что если заранее подумать о том, что включить в такт конвейера не придётся об этом думать потом.

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

Вечер добрый!
Собственно что касается проектирования авто, то тут стоит различать проектирование новой модели и ежегодное обновление модели, — вот второе весьма, как кажется похоже на выпуск новой версии ПО, т.к. конструкция радикально не меняется, а появляются новые опции за которые собственно и платит конечный потребитель. В софте аналогично видим более или менее регулярный поток обновлений/улучшений и редкие мажорные релизы со сменой архитектуры.


Сам по себе конвейер нужен для выравнивания нагрузки, переключения же при таком подходе возникают с той частотой которой мы их спланируем, можно чаще, а можно и реже чем agile-спринты. Идея здесь в том, что эффекта с выпуском версии раз в две недели можно добиться не только путём сокращения цикл разработки ПО до двух недель (при этом на продуктивную разработку будет потрачено примерно неделя ), но и конвейеризацией (при этом на разработку будет потрачено уже две недели). Просто большие непрерывные куски времени позволяю решать более сложные задачи, не занимаясь их искусственным дроблением, что иногда полезно (при перекладке математической теории на код, например)


Что касается рудиментарности операций — то тут как посмотреть:


  • если смотреть на суть работ т.к. программист практически всегда будет писать код, отличающийся от кода, который он писал в прошлом прошлом и так будет всегда — в этом суть
  • если смотреть на конвейер как на свободные куски времени, которые можно заполнить полезной работой, то всё же две недели больше чем одна для нерутинной работы

Т.е. однотипность не в составе работ, а в объёме свободного времени на эту работу.

Вечер добрый!
Собственно что касается проектирования авто, то тут стоит различать проектирование новой модели и ежегодное обновление модели, — вот второе весьма, как кажется похоже на выпуск новой версии ПО, т.к. конструкция радикально не меняется, а появляются новые опции за которые собственно и платит конечный потребитель. В софте, аналогично, видим более или менее регулярный поток обновлений/улучшений и редкие мажорные релизы со сменой архитектуры.


Сам по себе конвейер нужен для выравнивания нагрузки, переключения же при таком подходе возникают с той частотой которой мы их спланируем, можно чаще, а можно и реже чем agile-спринты. Идея здесь в том, что эффекта с выпуском версии раз в две недели можно добиться не только путём сокращения цикл разработки ПО до двух недель (при этом на продуктивную разработку будет потрачено примерно неделя ), но и конвейеризацией (при этом на разработку будет потрачено уже две недели). Просто большие непрерывные куски времени позволяю решать более сложные задачи, не занимаясь их искусственным дроблением, что иногда полезно (при перекладке математической теории на код, например)


Что касается рудиментарности операций — то тут как посмотреть:


  • если смотреть на суть работ т.к. программист практически всегда будет писать код, отличающийся от кода, который он писал в прошлом прошлом и так будет всегда — в этом суть
  • если смотреть на конвейер как на свободные куски времени, которые можно заполнить полезной работой, то всё же две недели больше чем одна для нерутинной работы

Т.е. однотипность не в составе работ, а в объёме свободного времени на эту работу.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории