May 21st, 2009

cartoon

Software People

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

Единственно, боюсь, не уложусь в 40 минут. И так пришлось откоцать от презентации почти все. Я просто не успею ничего сказать, например, про темпоральную логику и основания методики (поэтому она будет вводится "интуитивно" на основании auftragstaktik), не успею показать ее связь с сетевым планированием (сетевой график - один из частных случаев декларативного плана), и не смогу рассказать про то, как получить их "карты целей" сетевой график, и даже использовать схему при time boxing планировании.

К сожалению, я даже не успею показать ни одного примера реального плана проекта. Я для демонстрации придумал три плана:
1) Подготовка продукта к онлайн-продажам в США (иллюстрирует процесс решения проблем при составлении плана, увязывает воедино проблемы составления документации, решение организационных вопросов, и разработку)
2) Разработка движка медиаплеера (иллюстрация чистой хай-тек разработки).
3) Разработка программно-аппаратного комплекса (разработка ПО и аппаратуры одновременно, с элементами логистики в процессе разработки).

И ни один из них не успею показать. Дело в том, что только объяснение плана (2) займет не менее 5 минут. План (1) - вообще занял бы половину презентации.

Короче, все. Как есть, так есть. Выдвигаюсь на мероприятие.
cartoon

Читай код! HOWTO

Вдогонку к дискуссии к статье "Читай код". Сурен Самарчан сегодня буквально поразил меня новостью (для меня), о том, что, оказывается, есть цельная книга о том, КАК читать код. Характерны примеры. Почитайте.

http://en.wikipedia.org/wiki/Code_Reading
Code Reading (ISBN 0-201-79940-5) is a 2003 software development book written by Diomidis Spinellis. The book provides background knowledge and specific techniques for reading code written by others. It contains more than 600 concrete examples taken from important, real-life, open-source code systems like the Apache Web server, the hsqldb Java relational database engine, the NetBSD Unix distribution, the Perl language, the Tomcat application server, and the X Window System. The book covers most concepts related to code that are likely to appear before a software developer's eyes, including programming constructs, data types, data structures, control flow, project organization, coding standards, documentation, and architectures. A compact disc with 16 million lines of open-source code, accompanying the book, provides the complete context for all the presented examples. However the end chapters may be of most use to advanced users as the initial chapters delve into programming language constructs, regular expressions, etc.

И 16 миллионов строк самого разного кода, для чтения на досуге в нагрузку. :) Ну что я могу сказать?



:)

ЗЫ: Вообще, я собирался написать парную статью "Пиши код" :). Если руки дойдут, напишу.
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 процессы). Семантика "декларативного" плана и его связь с активностями.

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