Category: технологии

cartoon

Введение в NestedTypes

React ValueLinks, это конечно, хорошо, но пришло время рассказать о нашей основной технологии, которая лежит в основе продуктов Volicon/Verizon.

https://medium.com/@gaperton/introduction-to-nestedtypes-data-framework-69aff986287e#.nn1a3qsc7

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

Мы используем ее в сочетании вот с этим:
https://github.com/Volicon/NestedReact

Которое замещает стандартный React State нашими моделями, и мы получаем сквозную технику управления состоянием. С двухсторонним databinding, естественно - для этого используются наши линки, о которых я писал раньше.

Не побоюсь сказать - это самая совершенная на данный момент технология управления состоянием. И самая простая в использовании.
cartoon

Такие разные отчеты

10 лет назад, когда я поступил на работу в одну международную компанию (да CQG это, конечно, че там), я впервые столкнулся необходимостью написания отчетов.

Это был так называемый weekly report, в котором полагалось писать то, что ты сделал за неделю, и то, то собираешься делать на следующей. Он отправлялся руководителю группы.

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

Collapse )
cartoon

Инженерная деятельность, ошибки, и риски

Новый текст, рекомендуемый к прочтению перед моими презентациями про управление рисками в разработке ПО. Должен давать целостное понимание сути инженерной деятельности, и основных присущих ей рисков. Является обобщением опыта проектов в области разработки корпоративных БД, кастомного ПО на С++, веб-разработки, микроэлектроники, ПЛИС, печатных плат, телеком-приложений, и конструкторских работ по разработке корпусов. В общем, всей достаточно разносторонней херни, с которой я соприкасался.

Во всем перечисленном есть, видите-ли, кое-что общее.

Это относительно законченный фрагмент более крупного текста.

ЗЫ: А конструкторские работы по разработке серверных корпусов я вообще теперь программистам в качестве обязательного расширяющего сознание примера приводить буду. В инженерной деятельности, вероятно, нет, ничего настолько непохожего на программирование. Как хорошо, что я этим занялся. И как обычно, совершенно случайно, - но увяз. :) Захватило, сцуко. :) Микроэлектроника и платы - слишком сложны для примеров.

***

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

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

Collapse )
cartoon

Производственная ментальность

Из дискуссии на RSDN. Давно хотел об этом написать, и подвернулся повод.

Собственно, с лекции о "производственной ментальности" я начинал свой трениг в Одессе для Codedgers". Это - основополагающая "лекция", необходимая для правильного понимания всего моего материала. Здесь - в ужатом варианте. В полном варианте я очень детально рассматриваю конкретные проявления "производственной ментальности" в методологии PSP/TST, основанной на CMMI (могу, благо работал под ней и официально сертифицирован), и в сетевом планировании.

...

Ну да. Позже я пришел к выводу, что разделение на defined и empiric процессы само по себе не вполне корректное и не самое точное. Более правильно взглянуть на проблему под чуточку другим углом.

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

Collapse )
cartoon

Ag;)e Checklist

Готовясь к поездке в отпуск, я упаковывал трофейный рюкзак Microsoft, появившийся в доме после одной из конференций. И в одном из отделений я с изумлением обнаружил тонкую брошюрку под названием «Ag;)e Checklist. Очень краткое описание практик гибкой разработки». За авторством Асхата Уразбаева и Никиты Филиппова.

«Вот это называется - агрессивные методы продвижения», подумал я. «Как она туда попала?» Я посмотрел на невесть откуда взявшуюся брошюрку внимательнее. Брошюрка подкупала своей толщиной — со школьную тетрадку. «Черт бы тебя побрал, Асхат!» И, не в силах побороть любопытство, сел ее читать (это заняло примерно 5 минут). Но просто читать - это же скучно. Поэтому, я буду комментировать.

Collapse )
cartoon

"Центральное уравнение" продакт-менеджмента

Есть одна, сравнительно редко используемая категория классификации требований. А точнее сказать - потребностей. Которые надо отделять от _возможностей_, которые и есть по сути своей "требования". Ибо требование - есть нечто выдуманное из головы, а потребность - существует более или менее объективно. Три группы:
1) Если данная потребность не удовлетворена - человеку плохо. Если она удовлетворена хорошо - то человеку меж тем не становится хорошо. Ему становится нормально. Помните анекдот - как устроить так, чтобы человеку очень хорошо? В разных вариациях суть одна - начала сделайте человеку очень плохо, а потом верните как было. То есть, никакое качество реализации данной потребности не сделает человека счастливым.
2) Если данная потребность не удовлетворена - человеку нормально, как обычно. Однако, при удовлетворении ее - человеку становится реально хорошо. Приятно ему и радостно. То есть, без данной фичи человеку плохо не будет, однако мы в состоянии доставить ему щастье.
3) Без данной потребности человек будет несчастен, как в (1). Однако, если ее удовлетворить как следует, то он может быть вполне себе счастлив, как в (2).

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

Про данную классификацию сказано в майкрософтстком курсе по MSF. Курс, кстати, совершеннейший балшыт, чуть менее чем полностью, по крайней мере, если говорить о русском переводе книги. За исключением отсылки к данной классификации. Которая составляет примерно несколько страниц, и написана до такой степени дубовым, рыбьим языком, что надо потратить много усилий, чтобы понять суть. Идиотский график, который они приводят для иллюстрации, ухудшает понимание, а не облегчает его. Достаточно сказать, что данная классификация относится к потребностям, а не возможностям (требованиям), в то время, как она приводится в курсе в последнем качестве. Я привожу данную классификацию в адаптированной для нормальных людей форме.

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

Интересная штука, осложняющая практическое применение данной простой классификации к требованиям, состоит в том, что данная классификация потребностей вещь не постоянная, а меняющаяся во времени. Возьмем экстремальный пример. Для человека, не пробовавшего героин, он не представляет никакого интереса. Попробовавшему его в первый раз - он в большинстве своем доставляет (еще бы, он совместим с гормоном удовольствия), являясь потребностью категории (2). Затем как-то незаметно, ое перестает приносить какое-либо удовольствие, и становится потребностью категории (1). И человек понимает, что его жестко кинули, ибо в начале героин вовсе не был потребностью (1), он был (0).

Принцип понятен, поэтому возьмем, допустим, ксерокс. Вначале такой _возможности_ - моментально копировать документы, не было. Потребность, однако, объективно существовала. Маркетинговое исследование, проведенное по заказу компании Ксерокс перед запуском первых устройств в производство, показало, что ксерокс никому не нужен. "Что? Десять тысяч баксов?! Да я секретарше документ под копирку печатать отдам!!!". Примерно такие были отзывы.

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

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

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

То же самое может касаться и потребности группы (3). Имеем в данном случае как положительное, так и отрицательное подкрепление, так что разница будет в том, что качество определенно имеет значение. Пример данной категории - автомобиль, в случае, если это единственное приемлемое средство добираться на работу. Вы можете удовлетвориться минимумом затрат, и купить "классику", если приобретение более комфортного автомобиля сопряжено с большими сложностями. Но что-нибудь вы обязательно купите.

А вот что касательно (2) - да взять ту же машину. Если ее отсутствие не доставляет вам реальных неудобств, то вы, вероятно, не будете брать "классику", ибо ее вождение доставляет мало удовольствия, и его можно скорее терпеть. В данном случае, как говаривал Омар Хайям, "уж лучше голодать, чем что попало есть." Я, впрочем, в состоянии получать удовольствие и от вождения "классики", которая доставляет существенно больше "калины" (но несравнимо меньше цивика и цефиры со скайлайном) но я особый, нетипичный случай. :)

Однако, некоторые, поимев машину, вдруг понимают, что то что они считали потребностью (0) или (2), оказывается, после некоторого опыта использования является как минимум потребностью (3). А лишившись ее, и вовсе обнаруживают, что это вполне тянет на целый (1), и им нужна на время ремонта ЛЮБАЯ машина. Пусть даже "классика". Бывает, и еще как бывает. И не только, когда речь идет о машинах и героине.

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

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

Да ладно ксерокс. Вспомните iPhone. Как его мешали с дерьмом при его появлении! О. Да он в подметки не годится типо существующим коммуникаторам. Да он типо ммс отправлять не умеет (какого типа данная _потребность_, что там у нас с _возможностью_, и какой у нее потенциал? А сравнительно с электронной почтой?). И видео-то типо он не снимает. И камера-то типо у него мегапикселей мало имеет.

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

Фокус в том, что все устройства до iPhone умели в принципе то же самое или больше, но нарушали "центральное уравнение". А именно, проще было таки встать с дивана, и пройти к компу. Что ж, это урок всем нам, господа.

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

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

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

Yota

Недавно узнал о сети Yota. Потрясающий проект.

Несколько лет назад говорили о TriplePlay, - о том, что операторы связи будут вынуждены предоставлять комплекс из трех услуг (интернет, телефония, телевидение), чтобы остаться конкурентоспособным. Что мы видим сейчас?

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

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

Многие интернет-провайдеры, такие как Корбина, протягивают до квартиры пользователя Ethernet. По одному проводу они могут давать как дешевую телефонию (на основе протокола SIP), так и цифровое телевидение с интерактивными услугами, например - видео по запросу.

Для телефонных компаний, клиентская база которых подключена посредством телефонной витой пары, естественным способом предоставлять "продвинутые" услуги являются технологии xDSL. На самом деле, они обладают естественным преимуществом - провода на "последней миле" уже протянуты, и инфраструктуру разворачивать проще. Далее, они могут продавать продвинутые услуги на основе технологий IP, конкурируя с интернет-провайдерами. Московский МГТС этим уже занимается, кроме того - в Москве наиболее популярным провайдером услуг xDSL является Стрим.

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

Однако, провода это не единственный способ организации "последней мили". "Традиционные" беспроводные технологии представлены у нас в основном "телефонными" операторами сотовой связи, которые до последнего времени конкурировали с операторами проводной телефонной связи. У "телефонистов", как всегда, есть свой подход к организации быстрых сетей передачи данных - технологии 3G.

Но есть и соответствующая интернет-технология - WiMAX. Она выводит TriplePlay на новый уровень, включая в конкуренцию еще и операторов мобильной связи. WiMAX позволяет организовать мультисервисную беспроводную IP сеть, с большим радиусом охвата (стандарт допускает расстояния до десятков километров), с большими скоростями, и с принципом сотовой сети - перехват от вышки к вышке. И самое главное, она, в отличии от WiFi, позволяет управлять приоритетом трафика, отличая трафик реального времени, такой как телефония или телевидение, от простого трафика.

Что означает это на практике. В Москве, Питере, и Уфе появился WiMAX провайдер Yota с безлимитными тарифами. При условии хорошего покрытия города:
1) Для подключения к сети владельцу ноутбука достаточно будет воспользоваться USB-свистком или WiMAX-картой. Если WiMAX не будет вообще встроен в ноутбук. И у него будет высокоскоростной интернет не только дома или в офисе, а везде, где бы он не находился.
2) Это позволяет продавать приставки для интерактивного цифрового телевидения, которые заработают сразу из коробки, без каких-либо проводов, настройки, и дополнительного оборудования. И вы сможете легко перенести ее их комнаты в комнату без каких-либо проблем, все будет работать.
3) Имея коммуникатор с WiMAX, такой, как HTC MAX 4G, вы будете иметь с собой не только интернет, но и телевизор, радио, библиотеку фильмов, skype, и очень дешевый IP-телефон. Например, если у вас в офисе применяется IP-телефония, то не составит труда настроить IP-АТС так, чтобы она перенаправляла звонок на ваш экстеншн на ваш коммуникатор, и, если вы в зоне действия сети Yota, вы примете звонок, где бы вы не находились. И это вообще не будет стоить ничего. Входящие звонки на мобильный телефон будут для вас бесплатны. Да, этот коммуникатор может быть использован как WiMAX модем.

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

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

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

Этот сервис уже доступен в Yota бесплатно на два года, для покупателей HTC MAX 4G. :) Что там сони-эриксон говорит? "Loaded with music"? :) А телефон, заряженный на халяву несколькими сотнями тысяч композиций на два года - не хотите? :).

Подобная стратегия - сдвиг выручки между рынками. Yota делает музыку бесплатной, избавляя людей от необходимости платить за лицензионную музыку, и взымая освободившиеся деньги за другое - за сервис передачи данных. Подобные соображения движут компанией IBM, которая вкладывает деньги в open source. Компания, которая продает железо, имеет выигрыш с того, что софт становится бесплатен. :)

Второй интересный аспект подхода Yota - можно назвать вертикальной интеграцией. Телефон HTC MAX 4G был разработан HTC специально для Yota по заказу. В Yota есть программисты, которые пишут софт для HTC MAX. Да, телефон продается за деньги, а не раздается бесплатно. Но основной бизнес Yota - это продажа сетевого сервиса. При этом, Yota непосредственно занимается и контролирует все вопросы, связанные с предоставлением этого сервиса.

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

В лице Yota мы видим новый тип компаний, предоставляющих конечным пользователям сервисы связи, и одновременно - интеграцию этих сервисов с интернет-сервисами. Собственно, все сервисы Yota - internet-centric. Они действуют почти как Apple. Мы наблюдаем настоящий инновационный маркетинг, продакт-менеджмент, и разработку в действии, и самое удивительное, - это происходит средь бела дня в России, а не где-нибудь в Штатах или в Европе. Да, сеть Yota - первая крупная WiMAX сеть в Европе.

Пожелаем Yota удачи, и будем следить за развитием событий. Я намереваюсь оказаться в их центре, и не собираюсь пропускать самое интересное, и, поэтому, буду покупать HTC MAX 4G. :)

ЗЫ: Соответственно, продаю свою интернет-таблетку Nokia n810 - кому надо, пишите. :) И это, nokia e71 тоже продаю :).
cartoon

Software People: вторая презентация

Так получилось, что во второй день конференции один из докладчиков не смог прийти, и меня попросили его заменить.

Забавно, собственно, что. В первый день, когда я выступал с докладом про принципы разработки структуры плана, меня спросили - а что же насчет планирования сроков? Я ответил - "это тема другого моего доклада". Я на самом деле год назад делал доклад ровно на эту тему на другом мероприятии. Аудитории такой ответ понравился :).

И вечером, после выступления, организаторы мне сообщили, что от меня требуется доклад на замену. :) Забавно. Таким образом, во второй день я прочитал доклад о прогнозе сроков.

В принципе, в паре они _почти_ закрывают тему планирования. "Почти" - потому, что технику прогнозирования сроков я разработал независимо от декларативного "планирования", и задача их совмещения не так проста. Хотя...

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

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

Вторая техника - вот как ее срастить с "декларативным планированием" - честно говоря пока не думал. Ибо вопрос корелляций времени и объема на самом деле весьма не простой и далеко не очевидный. К примеру, PSP/TSP - методология, целиком построенная на метриках, статистике, и корелляциях, невероятно сложна. Ее просто невозможно внедрить самостоятельно не то что после 40-минутного доклада, но и после прочтения и понимания книги.

Техника 2 из второго доклада может быть, в отличии от PSP/TSP внедрена немедленно после доклада, и дает весьма неплохой эффект (value/cost существенно превышает PSP/TSP), но с первым докладом пока не стыкуется.

Итак, вот презентация.
http://www.slideshare.net/gaperton/ss-1479468

А вот и предыдущая - "декларативное планирование".
http://www.slideshare.net/gaperton/auftragsplanning-pre-final-1479467
cartoon

Декларативное планирование: презентация

Как и обещал, выкладываю презентацию к своему докладу.

http://files.rsdn.ru/20496/Auftragsplanning%20pre-final.pptx
Краткое содержание.

Текущее состояние дискуссии о процессах разработки - специалисты разбились на два лагеря. defined process (CMMI), empiric process (Agile).

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

empiric - соблюдение технологии не может гарантировать повторяемого результата. Акцент на итеративность и быструю обратную связь.

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

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

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

Truth is out there. Как на проблему глядят военные. Более практичный взгляд.

Auftragstaktik vs Beheflstaktik. Приказ в терминах действий. Приказ - миссия.
- как отдавать приказы
- как исполнять приказы, тип подчиненного, и корпоративная культура.
- Behefldtaktik как микроменедмент.

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

Как решается проблема планирования. Сетевое планирование = befehlstaktik. Потому и плохо работает. Активности -> цели = решение проблем = auftragstaktik = разработка ПО. Альтернатива традиционному подходу к группировке задач. Разработка плана от конечной цели. Свойства предлагаемой модели.

Паттерны в планах = "процессы". То, что будет часто встречаться в ваших планах. Цикл разработки RUP - как общий процесс решения проблем. Как обходится с итеративной активностью. Как выражается параллельная активность, и "параметрические" планы (aka процессы). Семантика "декларативного" плана и его связь с активностями.

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

Феерическая философия программирования

На RSDN есть форум "философия программирования". Хочу провести экскурсию по этому феерическому месту. На примере одной дискуссии, в которой вы, в частности, сможете познакомиться с "призраком оперы" данного форума, и общей атмосферой этого места. Это, в сущности, весело. It's supposed to be entertainment. Хотя некоторые вопринимают это место, и зловещие события, происходящие в нем, чрезвычайно серьезно.

Итак, (вспоминаем основную тему "призрака оперы") Пам! Па-ра-ра-ра-ра-ра-ра-ра-а-а-а-ам!! Та-ра-а-а-а-ра-рам!!!

взгляд со стороны

Сухой остаток или нетленные ценности

А вот и мой пост. Как же такое пропустить:
Слякоть, тлен, и суета сует.

"Здесь звучало мнение, что якобы законы эволюции технологии не отличаются от науки.

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

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

И.А. Негодаев. Философия техники
http://polbu.ru/negodaev_engineeringphilo/

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

Вы сидите сейчас под виндой? Самому понятию PC, такому, как оно есть сейчас, вы обязаны в первую очередь лично Гейтсу, и тем раздолбаям из IBM, которые приняли решение собирать IBM PC на базе открытых компонент, отдав при этом ключевую компетенцию — разработку ОС, на сторону Гейтсу, с правами неограниченной продажи (долго потом волосы на жопе рвали, да поздно). Именно это стечение личностей и обстоятельств в определенный момент времени и определило появление открытого стандарта PC, широкого рынка OEM-производителей. И определило весь вектор развития технологий вычислительной техники на последующие десятки (!) лет.

Маленькая компания Intel, например, сейчас ведущий производитель процов (кто бы мог подумать об этом в 80-м году), а их кривая в дугу х86 сейчас является доминирующей архитектурой (на смех бы подняли тогда, если кто предположил). Задумайтесь об этом — вот он, принцип преемственности и инерционности в инженерии в действии. А ведь все могло бы быть совсем не так. Вся история техники — это личности, появившиеся в нужное время в нужном месте. Think again.

Что же касается более фундаментальных и общих законов развития технологии — читайте книгу. Там все написано. Сами поймете, насколько далеко все ушло от наивных рассуждений "по аналогии". Эта тема волнует людей уже сотню лет как минимум, и каждый инженер должен быть знаком со своим "родным" разделом философии, ИМХО. Это стыдно не знать. 

PS: Философы, блин 
PPS: Спасибо Дворкин, читая твои опусы я заставил себя ближе ознакомится с философией техники, а это уже кое-что. Чего и другим желаю."