Скорость разработки

Умудрился я ввязаться в флеймо-войны - http://habrahabr.ru/blogs/pm/101906

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

Даже получилось толкнуть "парное программирование" в его команду. Теперь жду репортов об успешном внедрение.

Началось обсуждение с оценки эффективности программиста. В этот миф я не верю. Но вот попалась цитата, в которую я 100% поверю:

“Poor management can increase software costs more rapidly than any other factor.”
—Barry Boehm (Software Engineering Economics)

После этого я поменял свою точку зрения - людей мерять можно :)

Всегда ли прав клиент?

Часто звучит лозунг "клиент всегда прав!". Но насколько эффективен такой лозунг? Позволит этот лозунг писать качественный код и гордиться массовостью использования хорошего решения?

Давайте взглянем подробнее. Когда кто-то "прав", то кто-то значить "не-прав". Если прав клиент, то не права команда разработки. Но кто же создает продукт? Конечно же команда разработке. А в голове этой команды своя "правота", которая отличается от "правоты" клиета, а по сути является "не-правотой" клиента. Стаёт вопрос ребром - насколько я качественно сделаю продукт, если я считаю одно, а должен делать другое? Создаётся шизофреническая ситуация: думаю одно (истинное я), говорю второе (ну раз заказчик всегда прав - то буду говорить его же словами), а делаю третье. Что же такое третье? Симбиоз. Сибиоз, который готов взорваться. Некая субстанция, которая насильно скована контрактными обязательствами и деньгами. Проект может быть будет сделан. Но вы будете гордиться таким проектом? Будет ли каждый день работы приносить удовольствие от работы над ним? Я бы не стал так работать - жизнь одна, чтобы её портить на такую мелочную постановку задачи.

Но что же будет взамен "правоты". А взамен будет "партнёрство", в котором клиент и разработка суть партнёры. Партнёры, которые делают один проект, которые заинтересованы в его успехе. "Правота" вызывает механизм соподчинения я начальник - ты дурак. "Партнёрство" - это творчество равных. А если мы равны и мнение каждого важно, как своё. И мы руководствуемся продвижением продукта за счёт наших совместных усилий. То... Наступает сказка. Команда вовлекается в проект, клиент получает хороший продукт, пользователи летают на седьмом небе от счастья. Наступает мир и любовь! :)

Вывод: В общем для меня критерий "правоты" это неверный критерий. И вообще зло. И в этом я на 100% прав :)

В Agile дисциплина лучше, чем в Waterfall

Будьте внимательны, когда говорите, что waterfall дисциплинирует. Вотерфол прост и структурирует, но не дисциплинирует. Конечно там «дисциплина» воспринимается как следованию некоторым заранее определённым шагам, но не «дисциплине» в творчестве. А второй вариант «дисциплины» наиболее важен для нас.

Разработка в стиле Agile предполагает, что вы работаете профессионально, дисциплинируете себя в малом, и делаете это из-за дня в день. В вотерфоле нам сказали: в какое время и что делать (подготовка требований, разработка, тестирования) и как и кому передавать результаты своей деятельности. А на вопрос как это делать отнесли к компетенции работника. Agile, здесь я говорю больше об XP, плотно отвечает на вопрос как делать: как писать качественный код (TDD, Simple Design, YAGNI, парное программирование, постоянная сборка), как работать с требованиями (user stories, планирование итераций, приёмочные тесты FIT) и что делать с тестами. Я не хожу часто на левые совещания, я редко обновляю документацию, которую никто не читает (а если нужно, то это делается таской), но всё же моя работа более дисциплинирована чем в прошлой вотерфольной жизни.
Вотерфол демонстрирует «внешнюю» дисциплину – поставка чего-нить или какая-нить процессная церемония. Agile дисциплинирует участников проекта через их поведение и ежедневные активности. Лучше или хуже, но Agile оказывает большее внимание на стиль разработки и личную дисциплину.

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

За основу взят пост: link