ViPRosMoroZ.Ru,

да пиши, раз охота че то писать
я просто намекнул, что хорошо бы изучить предметную область что бы не сотворить очередную "ХакерсДизайнер" или как она там называлась и мариуполя

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

Petro123Для этого есть куча народу - Постановщик, Аналитик, Бизнес-аналитик и т.д.

И где же эта куча народа в данной ситуации? :) Кто из полутора программистов является аналитиком, а кто постановщиком? :)

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

Принципы разделения труда откуда пришли? Правильно! Из производства... Именно в сфере производства классиками менеджмента был выведен и сформулирован постулат об улучшении производительности персонала при разделения труда. Но производство значительно отличается от проектной деятельности, соответственно, и разделение труда при разработке того же ПО требует совершенно иных подходов. Это на заводе токарь может совершенно не разбираться в работе сварщика, сварщик в работе сборщика... В случае проектов, когда многое практически нераздельно, классическое разделение труда совершенно не подходит.

Petro123,

Совершенно не то.
Вот есть у нас алгоритм по доставанию вещей из шкафа:
открыть шкаф

взять нужную вещь

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

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

Petro123- ОДИН 1С писать?
- один к\ф Войну и Мир ставить?
- один диагноз больного ставить?
Или профессионалов всё таки нанять?
И не "программу", а ИС с ТЗ.

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

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

А что же тогда в случае, если нет и не может быть четких процедур, если приходится действовать в условиях неопределенности? Вот тогда функции должны иметь пересечение:


Наивно полагать, что если в одну комнату посадить талантливого программиста и грамотного финансиста, то непременно родится программа для финансового учета и анализа, если что-то и родится, то скорее всего это будет глубокое непонимание друг-друга. И всякие "прокладки" между аналитиками и программистами отнюдь не решают данную проблему.

когда заранее известны все перемены

читать как

когда заранее известны все переменные

Petro123,

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

Ну а теперь давайте попробуем маленько разобрать различные "инструменты качества". Термин "жизненный цикл программного обеспечения" родился не на ровном месте, он происходит от понятия "жизненный цикл продукции". Т. е. когда начались свистопляски со всякими там ISO, ИТ-индустрия не захотела оставаться в стороне, и пошла вслед за другими, попытавшись выработать свои собственные стандарты, после которых и начали рождаться различные инструменты ака водопады, XP и иже с ними.
А как же, собственно, появлялись всякие там ISO? Да очень просто: брались успешные организации, и смотря на них выводились универсальные постулаты, так и родились стандарты ISO. Но успешные организации-то не дураки, чтобы вот так брать и свой опыт со своими секретами выкладывать на всеобщее обозрение... Соответственно, "брали то, что давали", т. е. общие принципы. Потом это все систематизировалось и начали рождаться типа такого:
ISO 9004:2001 6.2 Работники6.2.1 Вовлечение работников
Руководству следует улучшить результативность и эффективность организации, в том числе систему менеджмента качества, через вовлечение работников и их поддержку.
В качестве помощи в достижении целей улучшения своей деятельности организации необходимо поощрять вовлечение и развитие своих работников посредством:
- планирования обеспечения постоянной подготовки и карьеры;
- определения ответственности и полномочий персонала;
- разработки индивидуальных и групповых целей, менеджмента выполнения процесса и оценивания результатов;
- содействия вовлечению работников при постановке целей и принятии решений;
- признания и вознаграждения;
- содействия открытому, двустороннему обмену информацией;
- постоянного анализа потребностей своих работников;
- создания условий, поощряющих нововведения;
- обеспечения эффективной групповой работы;
- информирования о предложениях и мнениях;
- использования измерений степени удовлетворенности работников;
- выяснения причин прихода работников в организацию и их увольнения

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

;)

Petro123Александр Пузаков,
я видел очень неглупого Аналитика ... женского рода.
Она говорила: "мне пофигу что анализировать".
И ведь была права, чертяка :)
...
И видел программистов, которым пофигу что программировать....
Так что... в каждой шутке есть доля правды...
Каждый должен своим делом...
Вы кто по увлечениям :) ?
Многостаночник?

Ну, возможно :) Везде по чуть-чуть :)