Перейти к публикации

Срок готовности программы


Рекомендованные сообщения

Ситуация взята из жизни.

Есть чётко сформулированное ТЗ и есть программист - подрядчик.

Когда ставилась задача спросили его самого:

-за месяц справишься?

-справлюсь.

Прошёл месяц, второй, третий разменяли... а программа так и болтается в виде сырого полуфабриката и не видать конца-края этой вроде бы отладке. Понятное дело, что в том конкретном случае имели место вполне объективные причины провала, но корень их всех сидел в классическом вопросе:

как правильно назначить программисту срок сдачи готовой программы?

P.S. Этот же вопрос задал другому программисту, а она в ответ говорит примерно таковы слова:

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

:g:
Ссылка на сообщение
Поделиться на других сайтах


Когда ставилась задача спросили его самого:

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

Начинать надо было с выяснения того какие программы, в какие сроки и с каким интерфейсом и прочей икебаной делал ранее этот программист.

Делал и похожие, и совсем не похожие, и простые, и сложные. Сроки тоже вроде как не срывал. Вопрос состоит в том, что надо как можно точнее спрогнозировать возможные объёмы дабы в рабочей неделе одного программиста не оказалось 170 часов, хотя бы он и пяткой в грудь себя со звоном ударял заявляя:

начатых мною программ никому не передам!

Ссылка на сообщение
Поделиться на других сайтах

Чем более подробно написано ТЗ, тем меньше разработчику придется думать и тем больше ему придется заниматься именно написанием кода и его отладкой.

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

Поэтому, после получения ТЗ, он должен составить план работ.

Ты должен вникнуть в план и в то, что он хочет сделать.

Если кодер очень старательный и страдает перфекционизмом, то нужно кастрировать его план, чтобы в первую очередь реализовывались самые основные вещи, а лоск будет наводить потом.

Еще очень важный момент, расставить даты и временные интервалы, когда он будет работать только по твоей теме, и когда будут завершены каждый из пунктов плана.

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

НАйдя причину разбирайся с ней - пугай; предлагай премию; ищи другого.

К сожалению, в данном ремесле все очень сильно зависит от человека.

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

Ссылка на сообщение
Поделиться на других сайтах

Чем более подробно написано ТЗ, тем меньше разработчику придется думать и тем больше ему придется заниматься именно написанием кода и его отладкой.

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

Иначе сказать, для этого непременно нужно и самому быть классным программистом?

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

ИМХО, в рассматриваемом примере ТЗ было написано достаточно подробно, вплоть до пошагового раскрытия каждой процедуры и ожидаемого вида интерфейса... но этого оказалось недостаточно.

Поэтому, после получения ТЗ, он должен составить план работ.

Ты должен вникнуть в план и в то, что он хочет сделать.

Если кодер очень старательный и страдает перфекционизмом, то нужно кастрировать его план, чтобы в первую очередь реализовывались самые основные вещи, а лоск будет наводить потом.

Еще очень важный момент, расставить даты и временные интервалы, когда он будет работать только по твоей теме, и когда будут завершены каждый из пунктов плана.

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

НАйдя причину разбирайся с ней - пугай; предлагай премию; ищи другого.

Изначально и была выделн некий набор упрощенных базовых процедур и даже одна самая ходовая из них, но только на уровне алгоритма, без привязки к возможным

13 if (A<N) go to 14

14 DO 15 (i=1,1000000000)

15 CALL SABOTASHE

STOP

END

С проектированием железок проще, обладая некоторой статистикой можно спрогнозировать приблизительный объём КД в листах формата А4 и поставить обоснованные сроки исходя из наличия да квалификации кадров.

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

С CAD-моделями уже сложнее, а ведь это тоже своего рода язык программирования! Иногда поражаешься как легко и просто опытный конструктор с большими навыками работы в системе решает задачи, о которые сломало все свои вумные головы не одно, и даже не два предприятия. Однако такого парня не посадишь проверять ВСЕ модели завода или КБ, разве что пусть он сформулирует принципы и алгоритмы оценки качества, а профессиональные программисты реализуют плагинчик.

Но какие могут быть применены критерии для определения обоснованности срока выпуска программы на языке высокого уровня?

Ссылка на сообщение
Поделиться на других сайтах

Иначе сказать, для этого непременно нужно и самому быть классным программистом?

Нет.

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

Это нормальная ситуация, не парься. Поэтому ты должен обставить процесс так, чтобы он был тебе понятен, в первую очередь.

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

Именно твою логику процесса и будет реализовывать кодер.

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

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

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

Ну а также ты видишь реально степень готовности твоего будущего приложения. Потом начнете по кускам сшивать блоки и тестировать уже в комплексе.

ИМХО, в рассматриваемом примере ТЗ было написано достаточно подробно, вплоть до пошагового раскрытия каждой процедуры и ожидаемого вида интерфейса... но этого оказалось недостаточно.

Если, как ты утверждаешь, ТЗ было полным, а оно все равно никак, то значит проблема в человеке. Видимо он отдает свое время чему-то еще. МОжет быть халтуре.

Но какие могут быть применены критерии для определения обоснованности срока выпуска программы на языке высокого уровня?

ПРограмма должна работать. А если формально:

1. Выполненная работа должна соответствовать ТЗ.

2. Должен быть пройден набор тестов - автоматическая система тестирования или сам сидишь и как папа Карло тычешь в экран отрабатывая все возможные комбинации.

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

Ссылка на сообщение
Поделиться на других сайтах

Это нормальная ситуация, не парься. Поэтому ты должен обставить процесс так, чтобы он был тебе понятен, в первую очередь.

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

В проектировании железяк это выглядит так:

функциональная схема -> общая компоновка -> электрическая принципиальная схема.

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

дурь каждого становится видна.

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

Повторюсь: свою структуру тебе нужно разложить в последовательность - что реализовывать в первую очередь, что реализовывать потом. На каком этапе можно будет проверить функциональность.

Совершенно верно, в производстве изделий работают теже принципы и чем грамотнее общее разложено на сборки - подсборки тем меньше получается всякого рода "броуновского движения" на всех этапах ЖЦИ. Однако "подводный камень" есть и тут:

-теоретику нужно во что бы то ни стало подтвердить преимущество своего решения над оптимальным;

-технологу хочется чтобы КД была настолько сильно адаптированна к конкретному производству, чтоб даже не требовалось писать техпроцесс;

-снабженцу/комплектаторщику надо чтобы всё делалось ни из чего иного, как из того что уже имеется на складе;

-схемотехник... тому зачастую вообще

что бы ни делать, только бы ничего не делать

- и т.п.

В общем:

коси и забивай!

Бороться с этим вредительством со стороны служб предприятия может и должен (!) менегер, но уровень его компетентности в технических вопросах, как правило, находится ниже плинтуса, а посему и вся эта братия очень легко обводит его вокруг пальца + делится уворованным. :thumbdown:

В связке постановщик - кодер очевидно должны будут иметь место подобные же казусы. Например: программисту нравится FORTRAN, а оптимальным языком для этой задачи являлся бы С++, то бишь в программе получится 1500 строчек вместо потребной 1000, со всеми отсюда вытекающими проблемами при отладке и в количестве пользовательских диалогов. Но как не будучи классным программистом отловить сие безобразие на раннем этапе?

Если, как ты утверждаешь, ТЗ было полным, а оно все равно никак, то значит проблема в человеке. Видимо он отдает свое время чему-то еще. МОжет быть халтуре.

Видимо по ходу дела так оно и было, только врядли можно вести речь о халтуре. Скорее всего опять всё упёрлось в управление, так сказать классическое:

спячка -> раскачка -> горячка -> наказание невиновных -> награждение непричастных

1. Выполненная работа должна соответствовать ТЗ.

2. Должен быть пройден набор тестов - автоматическая система тестирования или сам сидишь и как папа Карло тычешь в экран отрабатывая все возможные комбинации.

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

Хм... действительно, работать на доверительном уровне ныне уже нельзя. Приму к сведению.

Спасибо.

Ссылка на сообщение
Поделиться на других сайтах

В проектировании железяк это выглядит так:

Это монопенисуально во всех отраслях, где идет разработка силами белых и прочих обезьян:

абстракция

декомпозиция

итерация

или говоря по китайски - разделяй и властвуй.

Бороться с этим вредительством со стороны служб предприятия может и должен (!) менегер, но уровень его компетентности в технических вопросах, как правило, находится ниже плинтуса, а посему и вся эта братия очень легко обводит его вокруг пальца + делится уворованным. :thumbdown:

Тут все довольно таки банально.

Составляется структура работы вашего организма - предприятия, процесса разработки или чего угодно.

На входе ты имеешь материалы, время и деньги, а на выходе трату материалов, времени, денег и получаемое качество на единицу продукции.

Потом начинаешь изыскивать меры по снижению издержек на всех этапах. МОжно начать с понятных тебе этапов.

Если твои кренделя не способны придумать ничего в силу корумпированности или некомпетентности, то либо нанимаешь к себе в помощь новичка после ВУЗа, с горящими глазами и он еще не будучи задействованным в гнилой системе начинает рыть землю руками.

Или привлекаешь внешних аудиторов.

В связке постановщик - кодер очевидно должны будут иметь место подобные же казусы. Например: программисту нравится FORTRAN, а оптимальным языком для этой задачи являлся бы С++, то бишь в программе получится 1500 строчек вместо потребной 1000, со всеми отсюда вытекающими проблемами при отладке и в количестве пользовательских диалогов. Но как не будучи классным программистом отловить сие безобразие на раннем этапе?

Это все фигня. C++ не самоцель и ФОРТРАН тоже нормальный язык.

Это все критично, если тебе придется передавать код другому разработчику или привлекать дополнительных кодеров. Вот тут может встать вопрос совместимости и денег.

Написать прожку в Дельфи или VisualC или VisualBasic будет стоить разных денег и поиск кодера может занять больше времени.

Если приводить аналогию, то по большому счету SolidWOrks и Inventor близнецы братья.

Критично в этой ситуации как ты будешь работать со смежниками, т.е. вопрос совместимости данных.

Хм... действительно, работать на доверительном уровне ныне уже нельзя. Приму к сведению.

Спасибо.

Не за что.

Помни, что именно по этой причине и появились вские PLM за(мо/д)рочки - начальник хочет чтобы его владения были для него понятны.

ЧТобы было понятно кто что делает и куда бабки уходят и время.

Старайся вникать во все сам по мере возможностей.

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

Ссылка на сообщение
Поделиться на других сайтах

Помни, что именно по этой причине и появились вские PLM за(мо/д)рочки - начальник хочет чтобы его владения были для него понятны.

ЧТобы было понятно кто что делает и куда бабки уходят и время.

Хм, весьма полезный постулат, жаль только его не часто озвучивают в литературе и тырнете, наипаче же скромничают продавцы Workflow и PDM и именно перед менегментом. :wink:

Старайся вникать во все сам по мере возможностей.

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

В следующий раз так и наверно поступлю, а в данном конкретном примере похоже уже всё ясно. :glare:

Интересно, что по среднестатистическим подходам следует делать с личностями, которые совсем некомпетентны в теме создаваемой программы и даже не отдают себе отчёта в тяжести последствий провала, но имеют полулегальную возможность подгружать кодера другими работами? А с кодером, что так охотно ведётся на эти штучки?

Ссылка на сообщение
Поделиться на других сайтах
  • 2 месяца спустя...
Гость
Эта тема закрыта для публикации сообщений.
  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




×
×
  • Создать...