[karpa13a]

Вообще не аджайл стайл. :)

Я так понимаю, что разработка внутренняя. Множество вещей разрабатываются в первый и последний раз. В такой ситуации можно и НУЖНО менять ТЗ. Мало того - пытаться сразу разработать железобетонное ТЗ вредно.

мы разрабатываем что бы оно работало и приносило чтото полезное конторе или делаем ради делать?)

 

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

оно канеш, обычно, всплывает и может быть даже услышано.

но. затраты на до(пере)работку, если они спрятаны под первоначальным ТЗ падают на разработку (тупят, дебилы чо).

[jab]

мы разрабатываем что бы оно работало и приносило чтото полезное конторе или делаем ради делать?)

 

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

нарабатывавшиеся годами. Весь софт уникальный и без документации, rtfs style. :-)

[kapa]

Вообще не аджайл стайл. :)

Я так понимаю, что разработка внутренняя. Множество вещей разрабатываются в первый и последний раз. В такой ситуации можно и НУЖНО менять ТЗ. Мало того - пытаться сразу разработать железобетонное ТЗ вредно.

мы разрабатываем что бы оно работало и приносило чтото полезное конторе или делаем ради делать?)

 

Мы разрабатываем чтобы оно работало и приносило что-то полезное конторе, или делаем ради того, чтоб потом свалить ответственность на постановщика задачи? И пофиг, что он из соседнего отдела, и мы, поняв посреди разработки, как можно было бы сделать лучше, чделали всё по ТЗ и потеряли или недополучили кучу бабла?

 

Манифест Agile:

...

Люди и взаимодействие важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

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

 

То есть, не отрицая важности того, что справа,

мы всё-таки больше ценим то, что слева.

[Sergey Gilfanov]

Мы разрабатываем чтобы оно работало и приносило что-то полезное конторе, или делаем ради того, чтоб потом свалить ответственность на постановщика задачи?

А почему свалить? Это разве не его зона ответственности?

 

И пофиг, что он из соседнего отдела, и мы, поняв посреди разработки, как можно было бы сделать лучше, чделали всё по ТЗ и потеряли или недополучили кучу бабла?

А в этом 'посреди разработки' постановщик что, не участвует уже? И этого нового понимания никак не видит?

 

Манифест Agile:

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

[kapa]

Мы разрабатываем чтобы оно работало и приносило что-то полезное конторе, или делаем ради того, чтоб потом свалить ответственность на постановщика задачи?

А почему свалить? Это разве не его зона ответственности?

Ну нам отмазаться или бабла заработать?

Ну, допустим, его. А работу потеряли все.

 

 

И пофиг, что он из соседнего отдела, и мы, поняв посреди разработки, как можно было бы сделать лучше, чделали всё по ТЗ и потеряли или недополучили кучу бабла?

А в этом 'посреди разработки' постановщик что, не участвует уже? И этого нового понимания никак не видит?

Ну так я к тому, что железно следовать ТЗ не всегда полезно.

 

 

Манифест Agile:

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

Чем железное следование ТЗ всё меняет?

[Sergey Gilfanov]

Чем железное следование ТЗ всё меняет?

Тут возражение не столько про следование ТЗ, сколько про документирование. Чего и почему хотели + что, как и почему все это сделано так как сделано.

[ttttt]

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

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

 

Да и сами по себе ТЗ в софте - это наследие от других инженерных дисциплин, они тут только как наборы идей.

[Sergey Gilfanov]

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

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

[kapa]

Agile же не против документации.

[jab]

Да и сами по себе ТЗ в софте - это наследие от других инженерных дисциплин, они тут только как наборы идей.

 

Это следствие того, что слова имеют разные значения для разных людей. Например даже сам термин ТЗ все понимают по-разному. :-)))

Про itil, itsm, agile и pmbok я вообще молчу...

[Sergey Gilfanov]

Agile же не против документации.

Там выше.

Работающий продукт важнее исчерпывающей документации

Так вот. Это он сейчас работает. Пока разработчики еще есть и могут быстро починить, если сломалось. А когда они это делать перестанут?

[kapa]

Agile же не против документации.

Там выше.

Работающий продукт важнее исчерпывающей документации

Так вот. Это он сейчас работает. Пока разработчики еще есть и могут быстро починить, если сломалось. А когда они это делать перестанут?

Ну так он же всё равно важнее :)

Ведь, когда наступит "сломалось", возможно и чинить не нужно уже будет?

[ttttt]

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

[Sergey Gilfanov]

Ведь, когда наступит "сломалось", возможно и чинить не нужно уже будет?

Слишком оптимистично.

 

Ну так он же всё равно важнее :)

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

А если есть работающая система, но нет достаточной документации - то система останется в единственном числе. Ну или придется делать все с нуля/заниматься исследовательскими работами заново.

И что важнее получается?

[Sergey Gilfanov]

Чтобы самому примеры по поводу своей точки зрения не придумывать: google 'Institutional memory and reverse smuggling' или ее русские переводы 'Корпоративная память и обратная контрабанда.' Она, кстати, кажется уже на форуме обсуждалось. Ни и из практики - неужели ни у кого не было ситуации 'работает, а где и как провода идут/оборудование стоит - неизвестно'? Как раз последствия подхода, очень похожего на Agile методики.

[kapa]

Ведь, когда наступит "сломалось", возможно и чинить не нужно уже будет?

Слишком оптимистично.

Это смотря с какой стороны посмотреть. Возможно слишком пессимистично.

Выходит, что это просто жизненно :)

 

 

Ну так он же всё равно важнее :)

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

А если есть работающая система, но нет достаточной документации - то система останется в единственном числе. Ну или придется делать все с нуля/заниматься исследовательскими работами заново.

И что важнее получается?

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

[ttttt]

Чтобы самому примеры по поводу своей точки зрения не придумывать: google 'Institutional memory and reverse smuggling' или ее русские переводы 'Корпоративная память и обратная контрабанда.' Она, кстати, кажется уже на форуме обсуждалось. Ни и из практики - неужели ни у кого не было ситуации 'работает, а где и как провода идут/оборудование стоит - неизвестно'? Как раз последствия подхода, очень похожего на Agile методики.

Только это все вообще не о софте и даже близко к нему не относится.

[SergeiK]

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

А если есть работающая система, но нет достаточной документации - то система останется в единственном числе. Ну или придется делать все с нуля/заниматься исследовательскими работами заново.

И что важнее получается?

А вы с какой целью интересуетесь? :).

То есть, вы с какой целью ПО разрабатываете?

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

 

Во втором случае у вам и ТЗ и документация и полный цикл разработки.

А в первом - прототипирование и моделирование, стори и спринты. Документировать просто некогда, да и незачем, через две недели желания заказчика изменятся!

[kapa]

Чтобы самому примеры по поводу своей точки зрения не придумывать: google 'Institutional memory and reverse smuggling' или ее русские переводы 'Корпоративная память и обратная контрабанда.' Она, кстати, кажется уже на форуме обсуждалось. Ни и из практики - неужели ни у кого не было ситуации 'работает, а где и как провода идут/оборудование стоит - неизвестно'? Как раз последствия подхода, очень похожего на Agile методики.

Только это все вообще не о софте и даже близко к нему не относится.

+1

30 лет в софте....столько не живут.

 

Мы работаем по Agile около 6 лет. Документация есть. Все знают где что стоит/лежит и почему. Или знают где уточнить. На канбан-доске даже есть столбец специальный - документирование.

[Sergey Gilfanov]

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

...

Документировать просто некогда, да и незачем, через две недели желания заказчика изменятся!

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

[SergeiK]

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

...

Документировать просто некогда, да и незачем, через две недели желания заказчика изменятся!

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

Дык, да, так оно и есть на самом деле.

Исполнитель систему сдал? Деньги получил?

"После нам - хоть потоп!" (с).

 

Только и с большими тиражируемыми системами не сильно лучше бывает, особенно, если очнуться лет через 5-10, а то и 20!

[karpa13a]

Ни и из практики - неужели ни у кого не было ситуации 'работает, а где и как провода идут/оборудование стоит - неизвестно'? Как раз последствия подхода, очень похожего на Agile методики.

ладно провода. хрен с ними.

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

умер. в прямом смысле.

разработчик который это делал-поддерживал уволился.

чувак который полгода пилил это - увольняется.

сейчас пилит документацию по процессам а не по потрохам, потому как никто не знает толком "как это работает?".

 

отсутствие документации со стороны заказчика: а зачем нам трекеры? зачем нам формализм. "ты меня знаешь - я тебя знаю - погнали!"

отсутствие документации с разработки - а зачем - я же тут всё знаю.

 

теперь либо всё выкидывать, либо верить что вся математика правильна и никогда не заглючит)

[Kirya]

А тут еще раз, с вашего позволения, возражу.

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

В этом, конечно, самое стабильное - все задублировать, законсервировать, и отгонять всех реформаторов от возведенного мавзолея.

Я мыслю не катериями ролей архитекторов, а масштабами компании Тимура.

И показываю наглядно то, что получится, если все роли архитекторов

будут схлопнуты в одном человеке.

И эксплуатация тут приведена, как пример.

 

Но его-то место другое.

Архитектура - инструмент расшивки противоречий (я воспользуюсь вашей фразой), но не только, и не столько внутри IT, сколько между задачами бизнеса, и IT.

Если бизнес стабилен, и не меняется, а цена простоя - миллиард - стабильность и консервация наше всё! Хотя и тут разумность желательна :).

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

Если потребности бизнеса меняются, архитектура должна меняться.

И что ?

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

Ибо архитектура эксплуатации тоже кстати свалится на него.

Нужен Тимуру ещё один шлагбаумист в конторе - сомневаюсь.

 

Я сам чувствую некоторый диссонанс в звучании слова архитектура, которая в моем личном восприятии означает что-то недвижимое и монументальное, на века!. Оно плохо соотносится с понятием архитектуры, о котором я пишу :).

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

Так же и архитектура предприятия.

За главным архитектором города, как правило стоит если не проектный институт, то как минимум департамент мэрии.

А тут всего 1 (один) человек.

[SergeiK]

Я мыслю не катериями ролей архитекторов, а масштабами компании Тимура.

И показываю наглядно то, что получится, если все роли архитекторов

будут схлопнуты в одном человеке.

И эксплуатация тут приведена, как пример.

А сейчас как? Сейчас же, или кто-то имеет представление, как все работает целиком, и тогда все на нем и схлопывается.

Или такого представления уже ни у кого нет :). Я вот не могу сказать за Тимура, как у него обстоят дела.

 

 

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

Ибо архитектура эксплуатации тоже кстати свалится на него.

Нужен Тимуру ещё один шлагбаумист в конторе - сомневаюсь.

Ну, в общем-то да, конечно может отгородится.

Ну а Тимуру, что Тимуру мешает сейчас отгородится от изменений, заморозить все развитие? Ему же тоже так будет проще :).

Надо искать (выращивать у себя) человека, который будет заинтересован в развитии, которому будет не интересно сидеть на пачке документов ровно, и будет интересно приносить пользу компании.

 

Но вот смешивать архитектуру и эксплуатацию - никак нельзя!

Проекты и архитектуру - можно и полезно, ибо они, по сути, друг друга дополняют.

А вот эксплуатация, они контролирует, что там архитекторы и проекты навыдумывали, а проекты и архитектор проверяют, что творит эксплуатация.

 

Кстати, тут вполне себе гармонично вырастает Чендж Менеджмент из ITIL :).

Эксплуатация двигает свои какие-то изменения в ИТ, а архитектор и проекты их проверяют на разумность и соответствие архитектуре.

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

Но это отдельная тема, не буду тут её развивать.

 

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

 

 

Я сам чувствую некоторый диссонанс в звучании слова архитектура, которая в моем личном восприятии означает что-то недвижимое и монументальное, на века!. Оно плохо соотносится с понятием архитектуры, о котором я пишу :).

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

Так же и архитектура предприятия.

За главным архитектором города, как правило стоит если не проектный институт, то как минимум департамент мэрии.

А тут всего 1 (один) человек.

Конечно.

Это было исключительно про то, что само слово "архитектура", лично меня, смущало, и ассоциируется в голове не с движением, а с недвижимостью :).

А на самом деле может быть вполне себе динамическое понятие.

[frol13]

За главным архитектором города, как правило стоит если не проектный институт, то как минимум департамент мэрии.А тут всего 1 (один) человек

 

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

 

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

 

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

 

Программирование ничем не отличается по сути от других видов разработки - и это- РЕМЕСЛО в первую очередь, и только после овладением ремесла возможно проявляется искусство.

 

Ехал как-то в поезде с руководителем компании, осуществляющем автоматизацию процессов на крупных предприятиях с учетом их технологических и организационных особенностей. Он перестроил всю систему разработки под то, что это - ремесло. Жизнь заставила - подробнее - не буду. До этого - несколько "гениев" сидели долго думали и потом придумывали, после этого все начинали подключаться. Теперь все типизировано, все задачи расписаны, есть жесткие графики. Меня удивило то, что у него у каждого разработчика в реал-тайме через каждые 15 мин появляется окошко, в котором он отмечает, что сделано, а задач на одного человека длиннее чем на 4 час, не выдается. Если человек не справляется с задачей за 4 час - это проблема, разбирают, задачу раскалывают на более мелкие. Это эффективно работает - он в реальном времени может все проконтролировать - как выполняются этапы разработки, кто справляется, а кто завис, кому помощь требуется и т.д. У него очень дорогой персонал и нет текучки. Вот к чему стремиться надо.

 

Вспомяну еще по стариковски. В студенчестве, когда были позывы стать программистом, взяли меня кодером по нынешнему в команду разработчиков какой-то системы обучающей на новом тогда еще Паскале. Управляющий проектом измотал придирками - я свой модуль несчастный раз 5 переписывал - то алгоритм неэффективный, то память я не так использую, то не задокументировано все подряд- прямо в коде - комментами. И я бы подумал, что он просто дуболом нетворческий, если бы сам не видел, как он на ассемблере ваяет изменения в ядро ОС почти 10-ти пальцевым методом по конспекту кода.

 

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