VaiMR November 10, 2012 at 12:05 AM

Десять правил спокойной разработки

Website development

Введение

Современный темп разработки ПО просто поражает своей скоростью. Функционал всегда «нужен вчера». Зачем? Конкуренция — обойдут, обгонят. Времени тестировать нет, надо отгружать функционал, надо, надо, надо.

На помощь командам разработки приходят практики, методологии, подходы и четкие регламенты. Попробую сформулировать в виде десяти правил концепцию «спокойной» разработки. А она то вынудит использовать современные методологии разработки ПО. И заказчик спокоен, и нервы свои целы. Profit!

Проблема

В фильме «Пираты силиконовой долины» хорошо показаны замученные длительным марафоном разработчики Apple. А код уставшего разработчика часто неприятен даже ему самому на следующий день. Вывод — не писать уставший код. Да и производительность оставляет желать лучшего.

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

Перейдем к правилам «спокойной» разработки.

Правила

Срочных задач не бывает, бывают приоритеты
Если задача имеет фатальный приоритет, то о ней надо было думать еще неделю назад. Явная ошибка планирования. Либо был проигнорирован пункт 9 и «хомяк» грозится откусить пол руки;
Приступай к задаче после полного ее понимания
Типичная ошибка в больших системах. Что-то сделал, как-то проверил, получил нечто;
Наладь диалог с заказчиком
В любом проекте приходится искать компромиссы, расставлять приоритеты. Найти общий язык с заказчиком дорогого стоит;
Руководствуйся ТЗ
ТЗ будет идеальным при использовании пункта 3, поэтому проблем быть не должно. А если функционального элемента нет, то и делать его не надо;
Используй только проверенный код
Любой код должен проходить серьезный цикл проверки перед поставкой заказчику. Любые сторонние модули должны быть покрыты тестовым кодом и хорошо проверены. Свой код надо проверять в обязательном порядке, без исключений;
Рабочий день 8 часов
Очень полезный пункт. Порой надо себе об этом напоминать. Семья тоже требует внимания, да и здоровье свое надо беречь. Если не хватает времени, то смотри пункт 1.
Пиши документацию
Без документации нет функционала. К тому же, она экономит уйму времени, потому что достаточно дать ссылку интересующемуся. Если документация не понятна, устарела или имеет двойственную трактовку, то ее надо актуализировать;
Держи код в порядке
Ужасный код должен переписываться, а не врастать в систему. Нет времени? Поставь TODO и исправь в ближайшую свободную минуту;
Заказчик не лабораторный хомячок для экспериментов
Есть такой подход «стрельба трассирующими». Его можно использовать только в молодых и еще мало-функциональных продуктах. Как только продукт переходит в фазу зрелости, заказчик перестает мириться даже с самыми маленькими ошибками. Продукт должен быть идеален. Иначе будет снижаться лояльность, а значит и уровень оплаты работ;
Тестируй
Очень важный пункт. Если функция не имеет теста, то вообще ничего нельзя сказать о ее работоспособности. ПО нестабильно. Яркий пример SQLite. Вот почему эта БД успешно работает в самых разных системах.

Заключение

Берегите здоровье, пишите качественный код, получайте удовольствие от работы. Будьте спокойны! Какие еще на Ваш взгляд правила стоит упомянуть?

Tags:

Hubs:

Website development

Comments 138

NikitaTratorov November 10, 2012 at 12:27 AM
+1
Про SQLite не понятно написано. А так, сборник полезных советов получился. Мне, как начинающему свое дело, это будет полезно. По некоторым пунктам шишки уже набил. ТЗ это вообще святое.
- Radagast November 10, 2012 at 02:42 AM
  +26
  имелось в виду наверно то, что в SQLite в 1177 раз больше кода тестов, чем кода самого SQLite
  - Flammar November 13, 2012 at 05:21 PM
    
    0
    Подозреваю, что часть кода тестов — универсальная, и применима не только к SQLite. В частности, специально некорректный менеджер памяти, эмулятор краха приложения и деградатор файлов баз данных.
NikitaTratorov November 10, 2012 at 12:28 AM
0
Документацию действительно надо писать вместе кодом и обновлять, когда код меняется. Ибо потом не писать очень лень и время жалко.
- Cancel November 10, 2012 at 10:42 AM
  +1
  Я бы ещё добавил, что документацию нужно периодически пересматривать и помечать/удалять устаревшие куски. Неактуальная документация крайне вредна.
creage November 10, 2012 at 12:44 AM
+6
Касательно ТЗ — не всегда все так однозначно. Иногда (у нас, почему-то, довольно часто) Product Owner выкатывает User Story, в которой описаны весьма абстрактные acceptance criteria — что-то типа:

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

… и все. Команда придумывает, реализует, тестирует, и демонстрирует. Т.е. ТЗ как бы и есть, но его как бы и нет.

И мне кажется, так даже как-то комфортнее — остается место на креатив, фантазию, дискуссии. Когда все четко по списку — скучно и тоскливо ведь. Нет?)
- Oleg_Yozhik November 10, 2012 at 09:05 AM
  0
  Нет ничего хуже, чем когда заказчик начинает вдаваться в детали типа «текст от чекбокса поместите не справа а слева, а количество элементов в списке увеличьте до конца страницы, зачем там пустое место». Демотивирует на корню.
  - viklequick November 11, 2012 at 12:19 AM
    
    +11
    А как вам (не шучу!) такие перлы со стороны заказчиков?
    
    0. Подвиньте вот эту надпись на полсантиметра. Какие пиксели? Откуда взял? Я линейкой померял, поднес к своему 30" монитору пластиковую линейку и ей померял! Ну что за хрень — вам понадобилось пять итераций пока сумели отмерить линейкой! Чем вы там вообще занимаетесь?
    
    1. У вас в дереве когда ветка закрыта — плюсик нарисован. А надо — минусик! И мне плевать, что у всех остальных так же, у нас будет лучше. Юзеры поймут, я же понимаю!
    
    2. Вот тут у вас выбор одного из нескольких вариантов (радиогруппа). А чего это у вас вместо галочек кружочки?! Ну вот рядом же галочка в квадратике (чекбокс). Сделайте так же. Никто не запутается, чего вы ввзяли!
    
    3. Молодцы. Сделали. Теперь у вас множественный выбор (чекбоксы) и один из нескольких (радиобатоны) — выглядят одинаково. Это ж вообще непонятно стало! Сделайте мне чтобы когда одиночный переключатель — было кругленьким, ну как до исправлений. Что? Виды чекбокса и радиобатонов поменяются vice versa? Юзеры не поймут? Чего вы со своими юзерами пристали?! У нас они не такие тупые как вам кажется!
    
    4. Почему у вас на формочках такой унылый серый фон? Надо сделать красиво! Что значит "какого цвета"? Как мои гламурные розовые штаны! Что значит какой RGB?! Розовые! А вы что нарисовали? Это цвет задницы а не штанов!
    
    5. Вчера я своим топ-топам показывал вашу демонстрацию. Отлично прошло. Но! Когда я напечатал ее на бумагу, чтобы раздать памятки, то на бумаге анимация не работала! Что значит «невозможно» — на экране же есть!
    
    6. Вы пишете что архиважную фичу вы не смогли сделать так как я вам забыл рассказать что это. Это что — реально повод был эту фичу не делать?!
    
    7. Что значит «почему не отвечаете на емейлы третью неделю»? Футбол смотрю. И вообще, если я хоть час поработаю как вы просите, вы потом месяц будете плакать всей командой, лучше не надо. Да, и какой гад поставил моего босса в СС? Я по ошибке нажал reply all и он меня теперь хочет уволить! Сатрап, считает что футбол надо смотреть не в рабочее время. Некоторое время не буду отвечать — занят в профкоме, надо чтобы не уволили.
    
    Вот это были — реальные демотиваторы.
    - onehell November 11, 2012 at 12:46 AM
      
      +3
      
      Да, весело там у вас))
      
      0. Пять итераций для того, чтобы подвинуть надпись на пару пикселей (предварительно сделав нехитрые вычисления с учетом DPI) — действительно перебор.
      Пункты 1 и 2 и 3 требований я бы завернул. Объяснил бы заказчику, что есть общепринятый стандарт, и если поведение программы в корне отличается от поведения операционной системы, это, мягко скажем, запутывает. Если не поймет — сформулировал бы так, что на второй раз до него бы точно дошло.
      4. Сфоткать штаны, сделать цветопробу и соответствующим образом поменять фон. Клиент офигеет от внимательности, потом передумает (цвет соответствует, но не нравится), а мы выкатываем дополнительную трудоемкость и просим оплатить. В следующий раз клиент говорит себе: «да, ребята внимательные, делают то, что я прошу. Я в следующий раз буду думать прежде, чем просить — а вдруг самому не понравится?»
      5. Накурите клиента, анимация будет работать и на бумаге.
      6. Да, это повод не делать фичу, телепаты в отпуске.
      7. Для таких экземпляров нужно чаще ставить босса в CC, вдруг переведутся.
    - Goodkat November 12, 2012 at 01:47 AM
      
      +1
      
      Нарисовать 7 перпендикулярных линий красного цвета, 2 из которых зелёные и 2 прозрачные
      Петров пришел во вторник на совещание. Ему там вынули мозг, разложили по блюдечкам и стали есть, причмокивая и вообще выражая всяческое одобрение. Начальник Петрова, Недозайцев, предусмотрительно раздал присутствующим десертные ложечки. И началось.
      — Коллеги, — говорит Морковьева, — перед нашей организацией встала масштабная задача. Нам поступил на реализацию проект, в рамках которого нам требуется изобразить несколько красных линий. Вы готовы взвалить на себя эту задачу?
      — Конечно, — говорит Недозайцев. Он директор, и всегда готов взвалить на себя проблему, которую придется нести кому-то из коллектива. Впрочем, он тут же уточняет: — Мы же это можем?
      Начальник отдела рисования Сидоряхин торопливо кивает:
      — Да, разумеется. Вот у нас как раз сидит Петров, он наш лучший специалист в области рисования красных линий. Мы его специально пригласили на совещание, чтобы он высказал свое компетентное мнение.
      — Очень приятно, — говорит Морковьева. — Ну, меня вы все знаете. А это — Леночка, она специалист по дизайну в нашей организации.
      Леночка покрывается краской и смущенно улыбается. Она недавно закончила экономический, и к дизайну имеет такое же отношение, как утконос к проектированию дирижаблей.
      — Так вот, — говорит Морковьева. — Нам нужно нарисовать семь красных линий. Все они должны быть строго перпендикулярны, и кроме того, некоторые нужно нарисовать зеленым цветом, а еще некоторые — прозрачным. Как вы считаете, это реально?
      — Нет, — говорит Петров.
      — Давайте не будем торопиться с ответом, Петров, — говорит Сидоряхин. — Задача поставлена, и ее нужно решить. Вы же профессионал, Петров. Не давайте нам повода считать, что вы не профессионал.
      — Видите ли, — объясняет Петров, — термин «красная линия» подразумевает, что цвет линии — красный. Нарисовать красную линию зеленым цветом не то, чтобы невозможно, но очень близко к невозможному…
      — Петров, ну что значит «невозможно»? — спрашивает Сидоряхин.
      — Я просто обрисовываю ситуацию. Возможно, есть люди, страдающие дальтонизмом, для которых действительно не будет иметь значения цвет линии, но я не уверен, что целевая аудитория вашего проекта состоит исключительно из таких людей.
      — То есть, в принципе, это возможно, мы правильно вас понимаем, Петров? — спрашивает Морковьева.
      Петров осознает, что переборщил с образностью.
      — Скажем проще, — говорит он. — Линию, как таковую, можно нарисовать совершенно любым цветом. Но чтобы получилась красная линия, следует использовать только красный цвет.
      — Петров, вы нас не путайте, пожалуйста. Только что вы говорили, что это возможно.
      Петров молча проклинает свою болтливость.
      — Нет, вы неправильно меня поняли. Я хотел лишь сказать, что в некоторых, крайне редких ситуациях, цвет линии не будет иметь значения, но даже и тогда — линия все равно не будет красной. Понимаете, она красной не будет! Она будет зеленой. А вам нужна красная.
      Наступает непродолжительное молчание, в котором отчетливо слышится тихое напряженное гудение синапсов.
      — А что если, — осененный идеей, произносит Недозайцев, — нарисовать их синим цветом?
      — Все равно не получится, — качает головой Петров. — Если нарисовать синим — получатся синие линии.
      Опять молчание. На этот раз его прерывает сам Петров.
      — И я еще не понял… Что вы имели в виду, когда говорили о линиях прозрачного цвета?
      Морковьева смотрит на него снисходительно, как добрая учительница на отстающего ученика.
      — Ну, как вам объяснить?.. Петров, вы разве не знаете, что такое «прозрачный»?
      — Знаю.
      — И что такое «красная линия», надеюсь, вам тоже не надо объяснять?
      — Нет, не надо.
      — Ну вот. Вы нарисуйте нам красные линии прозрачным цветом.
      Петров на секунду замирает, обдумывая ситуацию.
      — И как должен выглядеть результат, будьте добры, опишите пожалуйста? Как вы себе это представляете?
      — Ну-у-у, Петро-о-ов! — говорит Сидоряхин. — Ну давайте не будем… У нас что, детский сад? Кто здесь специалист по красным линиям, Морковьева или вы?
      — Я просто пытаюсь прояснить для себя детали задания…
      — Ну, а что тут непонятного-то?.. — встревает в разговор Недозайцев. — Вы же знаете, что такое красная линия?
      — Да, но…
      — И что такое «прозрачный», вам тоже ясно?
      — Разумеется, но…
      — Так что вам объяснять-то? Петров, ну давайте не будем опускаться до непродуктивных споров. Задача поставлена, задача ясная и четкая. Если у вас есть конкретные вопросы, так задавайте.
      — Вы же профессионал, — добавляет Сидоряхин.
      — Ладно, — сдается Петров. — Бог с ним, с цветом. Но у вас там еще что-то с перпендикулярностью?..
      — Да, — с готовностью подтверждает Морковьева. — Семь линий, все строго перпендикулярны.
      — Перпендикулярны чему? — уточняет Петров.
      Морковьева начинает просматривать свои бумаги.
      — Э-э-э, — говорит она наконец. — Ну, как бы… Всему. Между собой. Ну, или как там… Я не знаю. Я думала, это вы знаете, какие бывают перпендикулярные линии, — наконец находится она.
      — Да конечно знает, — взмахивает руками Сидоряхин. — Профессионалы мы тут, или не профессионалы?..
      — Перпендикулярны могут быть две линии, — терпеливо объясняет Петров. — Все семь одновременно не могут быть перпендикулярными по отношению друг к другу. Это геометрия, 6 класс.
      Морковьева встряхивает головой, отгоняя замаячивший призрак давно забытого школьного образования. Недозайцев хлопает ладонью по столу:
      — Петров, давайте без вот этого: «6 класс, 6 класс». Давайте будем взаимно вежливы. Не будем делать намеков и скатываться до оскорблений. Давайте поддерживать конструктивный диалог. Здесь же не идиоты собрались.
      — Я тоже так считаю, — говорит Сидоряхин.
      Петров придвигает к себе листок бумаги.
      — Хорошо, — говорит он. — Давайте, я вам нарисую. Вот линия. Так?
      Морковьева утвердительно кивает головой.
      — Рисуем другую… — говорит Петров. — Она перпендикулярна первой?
      — Ну-у…
      — Да, она перпендикулярна.
      — Ну вот видите! — радостно восклицает Морковьева.
      — Подождите, это еще не все. Теперь рисуем третью… Она перпендикулярна первой линии?..
      Вдумчивое молчание. Не дождавшись ответа, Петров отвечает сам:
      — Да, первой линии она перпендикулярна. Но со второй линией она не пересекается. Со второй линией они параллельны.
      Наступает тишина. Потом Морковьева встает со своего места и, обогнув стол, заходит Петрову с тыла, заглядывая ему через плечо.
      — Ну… — неуверенно произносит она. — Наверное, да.
      — Вот в этом и дело, — говорит Петров, стремясь закрепить достигнутый успех. — Пока линий две, они могут быть перпендикулярны. Как только их становится больше…
      — А можно мне ручку? — просит Морковьева.
      Петров отдает ручку. Морковьева осторожно проводит несколько неуверенных линий.
      — А если так?..
      Петров вздыхает.
      — Это называется треугольник. Нет, это не перпендикулярные линии. К тому же их три, а не семь.
      Морковьева поджимает губы.
      — А почему они синие? — вдруг спрашивает Недозайцев.
      — Да, кстати, — поддерживает Сидоряхин. — Сам хотел спросить.
      Петров несколько раз моргает, разглядывая рисунок.
      — У меня ручка синяя, — наконец говорит он. — Я же просто чтобы продемонстрировать…
      — Ну, так может, в этом и дело? — нетерпеливо перебивает его Недозайцев тоном человека, который только что разобрался в сложной концепции и спешит поделиться ею с окружающими, пока мысль не потеряна. — У вас линии синие. Вы нарисуйте красные, и давайте посмотрим, что получится.
      — Получится то же самое, — уверенно говорит Петров.
      — Ну, как то же самое? — говорит Недозайцев. — Как вы можете быть уверены, если вы даже не попробовали? Вы нарисуйте красные, и посмотрим.
      — У меня нет красной ручки с собой, — признается Петров. — Но я могу совершенно…
      — А что же вы не подготовились, — укоризненно говорит Сидоряхин. — Знали же, что будет собрание…
      — Я абсолютно точно могу вам сказать, — в отчаянии говорит Петров, — что красным цветом получится точно то же самое.
      — Вы же сами нам в прошлый раз говорили, — парирует Сидоряхин, — что рисовать красные линии нужно красным цветом. Вот, я записал себе даже. А сами рисуете их синей ручкой. Это что, красные линии по-вашему?
      — Кстати, да, — замечает Недозайцев. — Я же еще спрашивал вас про синий цвет. Что вы мне ответили?
      Петрова внезапно спасает Леночка, с интересом изучающая его рисунок со своего места.
      — Мне кажется, я понимаю, — говорит она. — Вы же сейчас не о цвете говорите, да? Это у вас про вот эту, как вы ее называете? Перпер-чего-то-там?
      — Перпендикулярность линий, да, — благодарно отзывается Петров. — Она с цветом линий никак не связана.
      — Все, вы меня запутали окончательно, — говорит Недозайцев, переводя взгляд с одного участника собрания на другого. — Так у нас с чем проблемы? С цветом или с перпендикулярностью?
      Морковьева издает растерянные звуки и качает головой. Она тоже запуталась.
      — И с тем, и с другим, — тихо говорит Петров.
      — Я ничего не могу понять, — говорит Недозайцев, разглядывая свои сцепленные в замок пальцы. — Вот есть задача. Нужно всего-то семь красных линий. Я понимаю, их было бы двадцать!.. Но тут-то всего семь. Задача простая. Наши заказчики хотят семь перпендикулярных линий. Верно?
      Морковьева кивает.
      — И Сидоряхин вот тоже не видит проблемы, — говорит Недозайцев. — Я прав, Сидоряхин?.. Ну вот. Так что нам мешает выполнить задачу?
      — Геометрия, — со вздохом говорит Петров.
      — Ну, вы просто не обращайте на нее внимания, вот и все! — произносит Морковьева.
      Петров молчит, собираясь с мыслями. В его мозгу рождаются одна за другой красочные метафоры, которые позволили бы донести до окружающих сюрреализм происходящего, но как назло, все они, облекаясь в слова, начинаются неизменно словом «Блять!», совершенно неуместным в рамках деловой беседы.
      Устав ждать ответа, Недозайцев произносит:
      — Петров, вы ответьте просто — вы можете сделать или вы не можете? Я понимаю, что вы узкий специалист и не видите общей картины. Но это же несложно — нарисовать какие-то семь линий? Обсуждаем уже два часа какую-то ерунду, никак не можем прийти к решению.
      — Да, — говорит Сидоряхин. — Вы вот только критикуете и говорите: «Невозможно! Невозможно!» Вы предложите нам свое решение проблемы! А то критиковать и дурак может, простите за выражение. Вы же профессионал!
      Петров устало изрекает:
      — Хорошо. Давайте я нарисую вам две гарантированно перпендикулярные красные линии, а остальные — прозрачным цветом. Они будут прозрачны, и их не будет видно, но я их нарисую. Вас это устроит?
      — Нас это устроит? — оборачивается Морковьева к Леночке. — Да, нас устроит.
      — Только еще хотя бы пару — зеленым цветом, — добавляет Леночка. — И еще у меня такой вопрос, можно?
      — Да, — мертвым голосом разрешает Петров.
      — Можно одну линию изобразить в виде котенка?
      Петров молчит несколько секунд, а потом переспрашивает:
      — Что?
      — Ну, в виде котенка. Котеночка. Нашим пользователям нравятся зверюшки. Было бы очень здорово…
      — Нет, — говорит Петров.
      — А почему?
      — Нет, я конечно могу нарисовать вам кота. Я не художник, но могу попытаться. Только это будет уже не линия. Это будет кот. Линия и кот — разные вещи.
      — Котенок, — уточняет Морковьева. — Не кот, а котенок, такой маленький, симпатичный. Коты, они…
      — Да все равно, — качает головой Петров.
      — Совсем никак, да?.. — разочарованно спрашивает Леночка.
      — Петров, вы хоть дослушали бы до конца, — раздраженно говорит Недозайцев. — Не дослушали, а уже говорите «Нет».
      — Я понял мысль, — не поднимая взгляда от стола, говорит Петров. — Нарисовать линию в виде котенка невозможно.
      — Ну и не надо тогда, — разрешает Леночка. — А птичку тоже не получится?
      Петров молча поднимает на нее взгляд и Леночка все понимает.
      — Ну и не надо тогда, — снова повторяет она.
      Недозайцев хлопает ладонью по столу.
      — Так на чем мы остановились? Что мы делаем?
      — Семь красных линий, — говорит Морковьева. — Две красным цветом, и две зеленым, и остальные прозрачным. Да? Я же правильно поняла?
      — Да, — подтверждает Сидоряхин прежде, чем Петров успевает открыть рот.
      Недозайцев удовлетворенно кивает.
      — Вот и отлично… Ну, тогда все, коллеги?.. Расходимся?.. Еще вопросы есть?..
      — Ой, — вспоминает Леночка. — У нас еще есть красный воздушный шарик! Скажите, вы можете его надуть?
      — Да, кстати, — говорит Морковьева. — Давайте это тоже сразу обсудим, чтобы два раза не собираться.
      — Петров, — поворачивается Недозайцев к Петрову. — Мы это можем?
      — А какое отношение ко мне имеет шарик? — удивленно спрашивает Петров.
      — Он красный, — поясняет Леночка.
      Петров тупо молчит, подрагивая кончиками пальцев.
      — Петров, — нервно переспрашивает Недозайцев. — Так вы это можете или не можете? Простой же вопрос.
      — Ну, — осторожно говорит Петров, — в принципе, я конечно могу, но…
      — Хорошо, — кивает Недозайцев. — Съездите к ним, надуйте. Командировочные, если потребуется, выпишем.
      — Завтра можно? — спрашивает Морковьева.
      — Конечно, — отвечает Недозайцев. — Я думаю, проблем не будет… Ну, теперь у нас все?.. Отлично. Продуктивно поработали… Всем спасибо и до свидания!
      Петров несколько раз моргает, чтобы вернуться в объективную реальность, потом встает и медленно бредет к выходу. У самого выхода Леночка догоняет его.
      — А можно еще вас попросить? — краснея, говорит Леночка. — Вы когда шарик будете надувать… Вы можете надуть его в форме котенка?..
      Петров вздыхает.
      — Я все могу, — говорит он. — Я могу абсолютно все. Я профессионал.
      Ссылка на оригинал
      - VaiMR November 12, 2012 at 08:15 AM
        
        0
        
        Популярная байка с долей правды.
      - Vorchun November 12, 2012 at 08:29 AM
        
        0
        
        Спасибо! Давно так хорошо не было )))
      - Mezomish November 12, 2012 at 10:24 PM
        
        +1
    - Tomcat November 12, 2012 at 09:06 AM
      
      0
      
      6. Вы пишете что архиважную фичу вы не смогли сделать так как я вам забыл рассказать что это. Это что — реально повод был эту фичу не делать?!
      
      На самом деле, если добавить в конце. «А спросить/напомнить слабо было?», то высказывание кажется вполне логичным
    - Flammar November 13, 2012 at 11:02 AM
      
      0
      
      Не понял, про анимацию на бумаге — это реально?
      - airatshigapov November 13, 2012 at 11:22 AM
        
        0
        
        На экране же есть!
        
        Flammar November 13, 2012 at 05:25 PM
        
        0
        
        Я знаю, что на экране есть, я про то реально ли выкатывали требование сделать анимацию на бумаге?
        
        Кстати, в gmail в просмотре картинок прямо в письме анимации нет (по крайней мере не было 3 года назад).
- gasyoun November 10, 2012 at 09:50 AM
  +2
  Это не ТЗ а вектор мысли.
  - funca November 10, 2012 at 09:39 PM
    
    0
    так даже как-то комфортнее — остается место на креатив, фантазию, дискуссии
    
    Комфортно в начале проекта — когда всем хочется удивить мир, впереди еще уйма времени, все радостно делают оценки и ставят подписи под ТЗ.
    Ближе к дедлайну, когда креатив, фантазии и дискуссии бъют ключом, но времени уже нет и теги к документам мир по-прежнему не удивляют, приходит откровение, что они подписались под Теорией Заговора.
  - PM1630 November 12, 2012 at 06:20 PM
    
    0
    Извиняюсь. Не туда ответил.
- xanep November 10, 2012 at 02:43 PM
  +2
  > И мне кажется, так даже как-то комфортнее — остается место на креатив, фантазию, дискуссии.
  Одно другому не мешает. Просто в вашем случае ТЗ придется писать самим. После креатива, фантазии и дискуссий, вы все равно должны получить согласованный с Product Owner список требований. Иначе будут вечные переделки и нехватка времени.
  - Goodkat November 12, 2012 at 01:53 AM
    
    0
    ТЗ всё равно перепишется по ходу работы раза три, так как в процессе разработки, тестирования и внедрения выяснится, что что-то сделать невозможно, о чём-то забыли, что-то окажется неудобным для пользователей, что-то не было расчитанно на новые бизнес-процессы, что-то успело устареть и т.п. и т.д.
- Stas911 November 10, 2012 at 09:45 PM
  +2
  Дык а на что у вас аналитик? Пусть едет к заказчику, разбирается и приводит этот поток мысли к нормальному виду. А если аналитика нет — то увы, вам и париться.
haaji November 10, 2012 at 12:46 AM
+2
Пиши тесты, пиши документацию, тестируй, мой руки перед едой…
К тому же в компаниях покрупнее большую часть этих функций берут на себя менеджеры, тестировщики и аналитики.
- onehell November 10, 2012 at 02:48 PM
  +1
  Дополню: в компаниях покрупнее менеджеры должны выращиваться из технических специалистов, иначе они просто не будут понимать бед команды разработчиков, аналитиков, тестировщиков и документаторов.
  - Tomcat November 12, 2012 at 09:08 AM
    
    0
    Думаю, для того, чтобы понимать, что у команды проблемы и знать, кому их поручить выяснить и решать, технический бэкграунд не нужен. Нужна адекватность и хорошие тимлиды.
vsespb November 10, 2012 at 01:26 AM
+5
Юнит тесты — не для поиска багов. Они не заменяют ручное тестирование.
- OnYourLips November 10, 2012 at 09:29 AM
  +3
  А почему сразу юнит-тесты то?
  Почему вы не подумали о функциональных или интегрированных?
  - vsespb November 10, 2012 at 09:04 PM
    
    +2
    Я имею ввиду любые тесты, содержащие Mocking/Stubbing, служащие парадигмам TDD/BDD, тестирующие что-то одно в один момент времени. Они служат не для поиска багов в программе, а для дополнительного документирования логики, поиска регрессий, и как методология программирования.
    
    Под функциональными тестами всё чаще понимаются unit-тесты контроллеров MVC приложения. Интеграционные тесты хороши для большого рефакторинга.
    
    Ручное тестирование может заменить настоящий функциональный тест, без mock/stub, который пишет QA инженер (ну может быть и программист в одном лице), при этом
    — QA будет иметь дело с уже откомпилированной программой.
    — QA будет иметь спецификацию на все тестируемые им функции
    — QA будет всё равно что-то тестировать руками
    — во время написания теста, тоже что-то придётся сначала проверить руками.
    
    Врядли автор под одним термином «тесты» имел ввиду авто тесты QA инженеров и unit тесты.
- xanep November 10, 2012 at 02:48 PM
  0
  Все зависит от продукта. Если продукт — библиотека или фреймворк, то ручного тестирования может не требоваться вообще. В конце статьи яркий пример есть — SQLite. Зачем там ручное тестирование?
  - vsespb November 10, 2012 at 09:07 PM
    
    –2
    API, интерфейсы, библиотеки, протоколы точно так же можно тестировать руками. SQLite — добро пожаловать в SQL консоль.
    
    Если это библиотека, это автоматически не означает что TDD тесты с принципом — тестируй что-то одно, а остальное замени на mock/stub, могут заменить нормальное тестирование.
    - Flammar November 13, 2012 at 11:05 AM
      
      –1
      
      Руками можно не только тестировать, но и бухгалтерию вести по бескомпьютерной тетрадочной технологии…
      - Flammar November 13, 2012 at 05:15 PM
        
        0
        
        Если что, это была ирония… Руками можно много глупостей делать, это не значит, что их делать обязательно надо.
Dehumanizer November 10, 2012 at 01:40 AM
+14
Спасибо за статью, это просто открытие!
Никогда раньше не задумывался, да и вся полвековая история разработки ПО не додумались. Это круто, теперь все проекты будут успешны.
- xanep November 10, 2012 at 02:51 PM
  –1
  Вы можете писать сарказм сколько угодно, но скажите пожалуйста, в каком количестве компаний, после полувековой истории разработки ПО, процессы хотя бы с 3-м уровнем зрелости CMMI?
  - Neir0 November 10, 2012 at 03:05 PM
    
    +1
    В куче компаний. Конечно большинство из них не проходит сертификацию, поскольку это стоит очень дорого и имеет смысл для узкого круга заказчиков.
    - xanep November 10, 2012 at 03:21 PM
      
      –1
      
      Ну прям как в мультике «38 попугаев» — «куча — это сколько»? 3 это куча? а 4?
      Если брать в процентном соотношении, то вряд ли больше 20% компаний могут претендовать на подобный уровень. Не забывайте, что выстраивание процессов требует много времени и устоявшуюся компанию. Все стартапы начинают с 1-го уровня, многие из которых до 2-го вообще не доживают.
      - Dehumanizer November 11, 2012 at 12:02 AM
        
        –1
        
        Все ок, то что вы делитесь с санми вашим опытом, это уже круто, только все не так гладко. Сарказм говорит о том, что все все знают, вот только, как у всех, времени нет, не возможно писать крутой код, поскольку времени, банально, не хватает.
        Но сооброжения ваши очень кстати.
      - Flammar November 13, 2012 at 11:08 AM
        
        +1
        
        Кто-то из «великих» — то ли Фаулер то ли Грэхэм — писал, что самый лучший код он видел у мёртвых стартапов…
        
        xanep November 14, 2012 at 12:05 AM
        
        0
        
        Ни в статье, ни в моих комментариях нет ни слова про «лучший код». Обсуждаем оценку сроков. Вот статья, которая описывает зависимость оценки сроков от уровня зрелости в CMMI. Там же есть картинка (Figure 1), показывающая вероятность правильной оценки сроков на разных уровнях.
  - pansa November 10, 2012 at 05:20 PM
    
    –1
    «Писать сарказм» — это прелестно!
    
    Ладно. CMMI красивое название, но показывает в основном только готовность компании отлистать $$$ за пунктик в своей карточке. Что-то вроде наших сертификаций ФСТЭК, МО и прочих. Толку 0, но все при деле.
Krio November 10, 2012 at 02:13 AM
0
А в чем Вы пишете документацию? Прямо в коде или есть что-то дополнительное?
- VaiMR November 10, 2012 at 04:52 PM
  0
  Документация как в коде, так и в базе знаний confluence + хранилище различных Case-диаграмм.
NekR November 10, 2012 at 02:28 AM
+2
Такое ощущение, что пост написан на нервах.
- onehell November 10, 2012 at 05:31 AM
  +3
  Пост написан, прежде всего, не на нервах, а на печальном опыте.
  Вместо того, чтобы критиковать сложившуюся «авральную» технологию разработки, автор поста предлагает конкретные решения. И лично я с большинством их них согласен.
UFO just landed and posted this here
Yoh_Asakura November 10, 2012 at 05:06 AM
+2
Всё это конечно хорошо, и правила разумные, но неужели вы не видите что пост капитанство? Таких статей уже очень много и все об одном и том же.
Мне кажется, будет очень хорошо если вы теперь распишите, в отдельных статьях, каждое правило. Например «Срочных задач не бывает, бывают приоритеты» — каким образом расставлять приоритеты, на чем основываться, есть ли устоявшиеся задачи которые нужно решать в первую очередь? Если есть существующие методики, значит необходимо провести сравнительный анализ этих методик.
В общем — если делаете работу, делайте её хорошо. Просто получается, что написав такую статью, вы впустую отняли время, в первую очередь, у себя.
- onehell November 10, 2012 at 05:28 AM
  +1
  Внимательно почитал статью и комментарии, в том числе и твой. Не соглашусь с тем, что пост — капитанство.
  Я чуть меньше восьми лет участвую в разных проектах разработки и могу по опыту сказать, что в большинстве проектов действительно существует беда с менеджментом. Этот пост нужно распечатать для некоторых моих прошлых руководителей проектов и дать хорошенько вчитаться.
  
  Ты просто не понял смысла статьи, но это не значит, что она плоха.
  - Yoh_Asakura November 10, 2012 at 05:31 AM
    
    0
    Процитируйте пожалуйста меня, где я говорю о том что статья плохая.
    Я лишь сказал о том, что таких статей уже очень много и лучше было бы рассмотреть каждое правило в отдельности, больше пользы было бы.
    - onehell November 10, 2012 at 05:37 AM
      
      0
      
      По моим ощущениям в фразу «пост капитанство» вкладывался смысл «таких статей много, не стоило ее писать». То есть статье здесь делать нечего.
      
      У меня другое мнение.
      
      Статья полезна. Кратко и емко перечислены тезисы, а развернуть их не составит труда. Я постараюсь выделить время и написать чуть более развернутую статью, дополнив мысли VaiMR. Уверен, многим из нас будет интересно.
      - Yoh_Asakura November 10, 2012 at 05:48 AM
        
        0
        
        Ваше представление о статье отличается от моего.
        С удовольствием прочитаю вашу статью.
  - Flammar November 13, 2012 at 11:20 AM
    
    0
    в большинстве проектов действительно существует беда с менеджментом.
    И, тем не менее, в среднем по больнице получается успешно. Значит, менеджмент в среднем удовлетворительный и этот баг — минорный.
- VaiMR November 10, 2012 at 11:04 AM
  0
  В будущем попробую расписать каждый пункт более подробно в отдельных статьях.
- ncix November 10, 2012 at 07:51 PM
  0
  >>но неужели вы не видите что пост капитанство
  Тем не менее мало кто следует этим простым правилам. В том то и проблема что мы не хотим делать простые и очевидные вещи, о которых давно знаем
dstarcev November 10, 2012 at 06:52 AM
+17
Статья про мечты разработчика. Я и сам не против так работать. Но недостаточно знать что делать, еще нужно знать как делать. Ведь в реальной жизни все упирается во время. Может, в заказной разработке получится продать n-ное количество часов, требующихся на «идеальный процесс», но и закон Паркинсона никто не отменял.
Еще интереснее дела обстоят со стартапами, когда все быстро-быстро. Буду приводить примеры из реальной жизни.

>1.Срочных задач не бывает, бывают приоритеты
>Если задача имеет фатальный приоритет, то о ней надо было думать еще неделю назад. Явная ошибка >планирования.

Как планировать, если заказчик сообщил о задаче сегодня, а сделана она должна быть вчера?

>2. Приступай к задаче после полного ее понимания
>Типичная ошибка в больших системах. Что-то сделал, как-то проверил, получил нечто;

Как убедиться, что понимание полное? Что делать, если фича еще не спроектирована полностью, но сроки жмут так, что надо начать кодить хоть что-то?

>3. Наладь диалог с заказчиком
>В любом проекте приходится искать компромиссы, расставлять приоритеты. Найти общий язык с заказчиком дорогого стоит;

Что делать, если заказчик — чудак? Как найти общий язык?

>4. Руководствуйся ТЗ
>ТЗ будет идеальным при использовании пункта 3, поэтому проблем быть не должно. А если функционального элемента нет, то и делать его не надо;

В реальности ТЗ не будет идеальным. Скорее всего что-то будет не продумано. И времени на детализацию, конечно, нет.

>5. Используй только проверенный код
>Любой код должен проходить серьезный цикл проверки перед поставкой заказчику. Любые сторонние модули должны быть покрыты тестовым кодом и хорошо проверены. Свой код надо проверять в обязательном порядке, без исключений;

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

>6. Рабочий день 8 часов
>Очень полезный пункт. Порой надо себе об этом напоминать. Семья тоже требует внимания, да и здоровье свое надо беречь. Если не хватает времени, то смотри пункт 1.

Это возможно только при достаточно безразличном отношении к работе. Лично мне ответственность не позволяет просто встать и уйти, если надо сделать что-то важное. И меня поражает, когда так делают другие.
Сломал билд? Пошел пообедал. Не дофиксил баги к завтрашнему релизу? Пошел домой.

>7. Пиши документацию
>Без документации нет функционала. К тому же, она экономит уйму времени, потому что достаточно дать ссылку интересующемуся. Если документация не понятна, устарела или имеет двойственную трактовку, то ее надо актуализировать;

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

>8. Держи код в порядке
>Ужасный код должен переписываться, а не врастать в систему. Нет времени? Поставь TODO и исправь в ближайшую свободную минуту;

Ближайшей свободной минуты не бывает! :)

>9. Заказчик не лабораторный хомячёк для экспериментов
>Есть такой подход «стрельба трассирующими». Его можно использовать только в молодых и еще мало-функциональных продуктах. Как только продукт переходит в фазу зрелости, заказчик перестает мириться даже с самыми маленькими ошибками. Продукт должен быть идеален. Иначе будет снижаться лояльность, а значит и уровень оплаты работ;

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

>10. Тестируй
см. 5 пункт.

Но я бы очень хотел так работать, правда. Я иногда делаю это в своих снах.
- VaiMR November 10, 2012 at 11:07 AM
  +3
  В пункте 6 имеется в виду не «сломал и ушел», а мотивация в ограничении рабочего времени, чтобы более качественно планировать свою работу и делать все вовремя в спокойной обстановке.
- UFO just landed and posted this here
  - onehell November 10, 2012 at 02:18 PM
    
    +4
    Меньше восьми часов работать вполне можно, больше — уже перебор.
    
    Если на разработчика сваливается гора критичных задач или он каждый раз тонет в коде, разбирая баги, это повод задуматься: а все ли хорошо с проектом?
    
    И другой момент, но только поймите меня правильно: работать — не обязательно означает «выполнять должностные обязанности от звонка до звонка». Читать документацию и литературу, саморазвиваясь как IT-специалист, тоже можно на работе. Но если этого не получается, а жадный до информации мозг хочет ее получить, приходится заниматься IT в нерабочее время. А как же спорт, семья, хобби?
    
    Нет, я не лентяй и тоже когда-то упарывался, работая по 12-16 часов, но потом сравнил свою производительность и понял, что приличную часть этого времени просто туплю в монитор вместо того, чтобы решать задачи. Как следует выспался, переосмыслил все, что происходит, и стал выполнять ту же работу вчетверо быстрее. Теперь у меня есть свободное рабочее время, которое я вполне могу посвятить чтению и саморазвитию.
- onehell November 10, 2012 at 02:37 PM
  +2
  Как планировать, если заказчик сообщил о задаче сегодня, а сделана она должна быть вчера?
  По возможности лучше отказаться от сотрудничества с таким заказчиком. Поверьте, чудаков не большинство.
  
  Что делать, если фича еще не спроектирована полностью, но сроки жмут так, что надо начать кодить хоть что-то?
  Не нужно «хоть что-то». Чревато архитектурными ошибками, а в будущем — вкручиванием новых костылей-фиксов в старый фундамент. Время, затраченное на исправление этих косяков в ядре, легко можно потратить на написание новых функциональных блоков.
  
  В реальности ТЗ не будет идеальным. Скорее всего что-то будет не продумано. И времени на детализацию, конечно, нет.
  Согласен. Для выхода из этой нелепой ситуации я обычно работаю по такой цепочке:
  — сначала от заказчика добиваемся бизнес-требований (даже в самом запущенном случае они легко помещаются на распечатанный лист А4);
  — потом принимаем решение о том, нужна ли аналитическая проработка, ТЗ, проектная документация. Если нет — сразу начинаем проектировать и реализовывать, если да, то чуть погодя.
  
  В спорных случаях решающую роль играет утвержденный текст бизнес-требования. И от того, насколько четко и понятно они были сформулированы, зависит в целом успех работ по направлению.
- yul November 10, 2012 at 04:39 PM
  +2
  Как планировать, если заказчик сообщил о задаче сегодня, а сделана она должна быть вчера?
  
  Дать понять заказчику, что чудес не бывает, вписать задачу в расписание с реалистичными сроками исполнения. Иначе он так и не научиться планировать самостоятельно, и такое будет повторяться из раза в раз. Если вы, в остальном, работаете с нормальной скоростью, негативных последствий быть не должно. А если будут — значит, заказчик проблемный, тут уж решайте сами по ситуации, я бы его сменил.
  
  Как убедиться, что понимание полное? Что делать, если фича еще не спроектирована полностью, но сроки жмут так, что надо начать кодить хоть что-то?
  
  Выжимать крупицы информации, пока не станет ясно, что и как должно выглядеть и работать. Резюмировать своими словами в таск трекере и подтверждать у заказчиками со словами «делаю, как написано», доработки — за отдельную плату (при фикс. оплате).
  
  Что делать, если заказчик — чудак? Как найти общий язык?
  
  складывается впечатление, что вам надо искать нового заказчика.
  
  Наверное, существуют команды-звезды, в которых все разработчики умеют работать по TDD достаточно быстро, не тратя время на обучение. Но в реальности на внедрение TDD в большой команде нужно дополнительное время, которого, как вы уже знаете, нет.
  
  Не могу сказать насчёт команды, но лично для меня освоение TDD с нуля требовало времени ничуть не больше, чем ручное тестирование. Вы ведь всё равно будете тестировать? А если есть человек, который знает на практике, как лучше всего построить набор тестов, чтобы другие могли взять его за образец и задавать вопросы, как лучше реализовать тот или иной тест, так ещё лучше. Было бы желание у команды, а для этого надо убедить, что TDD не требует больше времени и усилий, чем ручное тестирование. Добавлю, что для команды TDD ещё важнее, чем для одного разработчика, имхо.
  
  >8. Держи код в порядке
  >Ужасный код должен переписываться, а не врастать в систему. Нет времени? Поставь TODO и исправь в ближайшую свободную минуту;
  Ближайшей свободной минуты не бывает! :)
  
  Вот именно, поэтому я переписываю плохой код сразу. Если не назрел серьёзный рефакторинг, конечно, тогда приходится ждать, когда становится посвободнее. Вообще, у вас как-то совсем плохо со временем, не давайте заказчику вас загонять, от хороших разработчиков он всё равно никуда не денется, а баги из-за спешки и переработки всё равно на вас повесят.
  - UFO just landed and posted this here
    - yul November 10, 2012 at 05:28 PM
      
      0
      
      Так можно всех заказчиков растерять.
      Тем более, что куча конкурентов работает с такими заказчиками.
      
      Не всех, тех кто считает себя пупом мира и не в курсе слова «сотрудничество». И я думаю, вы недооцениваете количество клиентов ) Либо у вас очень узкая специализация.
      
      Даже на проекте размера в месяц собственно разработки такая метода «уточнять пока не будет все ясно» — могут вылиться и в полгода уточнений.
      И, что примечательно, нет никакой гарантии, что все описано полно: очень много нюансов всплывают только при начале эксплуатации системы.
      
      Не представляю, каким образом, вы заказными письмами через Почту России общаетесь?
      Ваши обязанности ограниченны ТЗ, если всплыли непредусмотренные ньюансы — это проблема заказчика. Вы можете пойти навстречу, если это что-то небольшое, но если оказалось, что заказчик не сказал что-то существенное, то это только его вина, а не то, что вы «не спросили». Не надо брать на себя все риски. Но дело ваше, конечно )
      - UFO just landed and posted this here
        
        onehell November 10, 2012 at 06:31 PM
        
        +2
        
        Денис, вы пытаетесь говорить о разных вещах.
        
        Да, заказчик не должен разбираться в айти. Но он должен уметь корректно составить бизнес-требования. При этом он должен понимать: любое изменение формулировки требований на середине этапа разработки скажется на сроках, поэтому внятно формулировать свои требования нужно с самого начала.
        
        UFO just landed and posted this here
        
        onehell November 10, 2012 at 09:04 PM
        
        +1
        
        Да, ваш пример очень распространен.
        
        Чтобы не допустить такой ситуации, достаточно было задать вопрос: «перенос нужен однократный или потребуется возможность повторного»? Чтобы задавать такие и подобные вопросы, согласитесь, нужен опыт и некоторая дотошность.
        
        Формально: подписание технического акта означает согласие принимающей стороны с корректностью реализации. Трактовка требований неоднозначна. Здесь я полностью на стороне разработчика, но приложил бы максимум разумных усилий для того, чтобы сохранить лояльность заказчика.
Monaxxx November 10, 2012 at 07:54 AM
+5
10 правил для разработчика в вакууме.
- VaiMR November 10, 2012 at 11:18 AM
  +1
  Аргументируйте.
  - Monaxxx November 10, 2012 at 12:43 PM
    
    0
    А Вы сами соблюдаете эти правила полностью?
    
    Если нет, то Вы сами этим и про аргументировали.
    Если да, то срок разработки ПО и коммерческое составляющая окупаются?
    
    А то какой толк от почти идеально написанного ПО, которого заказчик так и не дождался и готов ли заказчик оплачивать идеальный код?
    - mishadoff November 10, 2012 at 03:05 PM
      
      +2
      
      Напомнило:
      
      Your code may be elegant, by mine fucking works.
    - VaiMR November 10, 2012 at 05:14 PM
      
      +1
      
      Стараюсь соблюдать эти правила, исключения бывают редко, да и по большей части, из-за ошибок планирования.
      
      Заказчик не дождался кода — это крайний случай. Очень хорошо об этом пишут классики. В этом случае заказчик или исполнитель недооценивает объем работ. Часто обе стороны излишне оптимистичны. Да и срок во многих случаях не так важен, как надежность: медицинское оборудование, встраиваемые системы, военная техника, высоконагруженные системы. Зачем заказчику ПО «быстро», если оно его может завтра убить, разорить, ну или подпортить репутацию.
      
      Макконелл по этому поводу сказал хорошую фразу, которой я стараюсь придерживаться: «Профессионал отличается умением указать на наличие проблем, не смотря ни на какое давление, и предложить план действий» (своими словами). А сколько книг написано по командным антипаттернам…
      - Monaxxx November 10, 2012 at 11:10 PM
        
        0
        
        Д.к. про что я и говорю, стараются, это не соблюдать, поэтому и вакууме.
        
        Я совершено согласен что приблизить продукт к идеалу это было бы крута, но мы живем в реальном мире, где время играет большую роль.
        
        Быстрое ПО заказчику принесет прибыль, и не важно что там будут баги, поправят в следующих релизах, главное что он успел выйти с продуктом на рынок.
        
        Сколько я встречал бытовою технику с ошибками, не работала должным образом та или иная функция, но она подорвалась все ровно.
Grigorieff November 10, 2012 at 11:09 AM
0
Проектировать код и архитектуру, перед тем как садиться и писать код.
EvilsInterrupt November 10, 2012 at 11:29 AM
0
Предложил бы:
1) Улучшайте коммуникации внутри команды
2) Находите время для повышения профессионализма сотрудников в рамках задач нужных продукту
3) Учитесь договариваться внутри команды вместо «Если бы ты это сделал, то ...». Это частный случай п.1, но достаточно важный. Куда важнее сделать дело, а потом в свободную минуту разобраться в ситуации, чем валить друг на друга тонны оскорблений
- onehell November 10, 2012 at 02:40 PM
  0
  Возможно, задаю слишком очевидный вопрос, просто хочу лучше понять, что вы имеете в виду.
  Приведите пожалуйста пример из практики, когда становится понятно, что коммуникации внутри команды нужно улучшать?
  - EvilsInterrupt November 10, 2012 at 05:56 PM
    
    0
    1) Команда сидит в одном помещении, но никто ни с кем не общается ни технически ни приятельски. Была ситуация, до того как я ушел от туда, когда выяснилось что в один и тот же момент два человека по разным углам зала писали один и код для достижения одной и той же цели.
    2) Возникло «мягкое место» и вместо того чтобы сесть решать проблему, ребята начали друг на друга «Какого фига ты… не сделал?», а в ответ «Да если бы у меня было… которое ты должен был сделать на прошлой неделе». Вобщем команда всячески пыталась найти кого-нить на кого можно свалить вину, вместо того чтобы принять «мягкое место» как факт и начать устранять проблему!
    3) В некотором уголочке сидит супер-мэн, который пишет адски быстро код, а как к нему подходишь с «тривиальщиной» вместо того чтобы лаконично и ясно рассказать или хотя бы послать в нужный мануал, начинает «а гугл тебе на что?». Оно понятно что человека может бесить когда его спрашивают часто одно и тоже, но в рамках конторы он винтик целой конторы и если другому винтику надо закрутиться и он это может сделать, то какого хрена? Все делают общее дело и в рамках конторы эгоцентризм лишнее и вредит бизнесу!
    - onehell November 10, 2012 at 06:43 PM
      
      +1
      
      О да, прекрасно вас понимаю.
      
      Когда в начале своего становления как программиста я столкнулся с п.1, решил не заморачиваться и просто сменил проект. Нервы дороже.
      
      Спихивание вины — это проблема людей. Стараюсь не связываться со «стрелочниками». К сожалению, не всегда получается.
      
      Сейчас могу уверенно ответить с позиции этого самого супер-мэна. Здесь я вижу два объяснения:
      1. возможно, он действительно эгоцентрист, либо страдает неуверенностью в себе и не хочет, чтобы кто-то набирался знаний и стал лучше него.
      2. компания, зная его талант, старается выпользовать его на полную, закидывая задачами, и у него объективно (!) не хватает времени на то, чтобы оторваться от кода и понятно развернуто ответить. Все мы прекрасно знаем, что отрываясь хотя бы на пять минут от «потока», приходится примерно с полчаса возвращаться «обратно в код».
      
      Я сам никогда не отказывал в помощи коллегам, но всегда приучал команду к тому, что задавать вопросы тимлиду нужно только в том случае, когда уже изучен гугл и техническая документация, а ответа не найдено. Было время, когда я говорил «ок, давай погуглим вместе — а вот и ответ на твой вопрос, читай».
      - EvilsInterrupt November 10, 2012 at 07:46 PM
        
        +1
        
        Какой бы не был вариант п.1 или п.2 в любом случае обучение новичков позитивно скажется как на гуру, так и на компании!
        Какие могут быть сценарии?
        1) Гуру могут схэдхантить и предложить больше халявы и при этом больше денег в другой конторе и повыше статус!
        2) Гуру может взять отпуск на месяц и больше
        3) Проект может работать в авральном режиме, а гуру пригласили на свадьбу и его нету!
        4) Гуру срочно перевели на помощь другому проекту
        
        Ситуаций много! Всех не перечислить. Для проекта и компании стратегически выгодней, когда гуру вырабатывает правильную схему обучения новичков и учат их.
        
        А что же для гуру выгодно?
        * Он может делегировать часть работы. После 2-3 раз новички как правило могут сами. Врядли кому-то нравится выполнять примитивные и надоедливые задачи достаточно долго.
        * Статус. Многих гуру радует когда на них смотрят как чуть ли не на богов :)))
        * Кандидаты в свою команду. Гуру может решить когда-нибудь, что пора бы и запилить чего-нить толковое и не редко ему нужны люди. А новички бывают разные, из них иногда можно выбрать кого-нибудь
        
        Рациональный подход к обучению новичков, а это один методов развития коммуникации в команде стратегически важно для почти любого проекта
        
        onehell November 10, 2012 at 09:08 PM
        
        +1
        
        Да, абсолютно верно.
namezys November 10, 2012 at 11:41 AM
+1
Почему магическая цифра 8? Не 6. И не 10? Потому что у нас так принято?
- VaiMR November 10, 2012 at 11:54 AM
  0
  Не понял вашу мысль, поясните.
  - skorm November 10, 2012 at 12:07 PM
    
    0
    Видимо имеется в виду продолжительность рабочего дня.
    - VaiMR November 10, 2012 at 12:11 PM
      
      0
      
      В этом случае, да, у нас так принято.
Vorchun November 10, 2012 at 03:28 PM
+3
Я пишу ТЗ.

Много пишу. Пробовал разные подходы. Понял одно — все никогда не учесть. Увы, многие, пользуются ТЗ как аргументов выбить денег. На самом деле всегда найдется пару мелочей, на которые вы с заказчиком по-разному посмотрите. Одну и ту же фразу можно понять по-разному. Поэтому часто еще все объясняется на словах. Но слова — ветер.

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

ТЗ — это цель проекта. Конечно, основные вещи там прописаны. Но в нашем случае — есть прототип (чаще всего интерактивный), а ТЗ — это комментарии. Объемные, но комментарии. Ну и также описание элементов на странице для дизайнера, чтоб не упустил.

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

Остается только решить что со сроками и бюджетом. И, может, надо ли согласовывать с заказчиком.

Т.ч. ТЗ — это конечный пункт, а не 100% истина

ЗЫ: можно убить год на все нюасы в документе, а через год прийти с заказчиком к тому, что проект уже и не нужен ))
Veterinar November 10, 2012 at 07:53 PM
+2
Стоит понимать, что использование того же Agile без перехода на принципиально другой ценовой уровень невозможен. Себестоимость проекта возрастает порой даже не в два раза. Все эти пункты должны быть целью компании в целом, если специалисты по поиску клиентов после внедрения всего этого не изменят ценовую политику, компания вылетит в трубу.

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

Техническое задание. У кого хоть раз был клиент с бюджетом больше 400 000 руб и своим вменяемым техническим заданием? У вас? Поздравляю, вы лжец. Профессиональное техническое задание на более-менее сложный продукт это, по опыту, +10% бюджета. Плюс время на интервью. У вас должен быть достаточно состоятельный клиент.

Я это к тому, что нужно всё это понимать, прежде чем приходить к руководству со словами «я всё понял!».
- Maccimo November 10, 2012 at 08:10 PM
  0
  Юнит… тестирование, это всё очень хорошо, но, опять же, сначала нужно выйти на клиента, который будет за это платить, если бюджет проекта меньше 10 тонн зелени, можно даже не заикаться об этом.
  Это как?
  Заказчик платит отдельно — пишем юнит-тесты, не платит — не пишем?
  Мы их для галочки пишем или всё же для удобства разработки?
  Привыкнув работать с использованием unit-тестов работать без них становится неуютно.
  - Veterinar November 10, 2012 at 08:12 PM
    
    +1
    В том плане, что написание юнит тестов дает кучу преимуществ, но требует дополнительных денежных затрат, т.к. занимает время. Иногда это допустимо, иногда нет.
    - EvilShadow November 10, 2012 at 09:37 PM
      
      +1
      
      Написание тестов не только занимает время, но и экономит его. Причём занимает оно рабочее время, а экономит личное, потому что после работы или в выходной не придётся в мыле чинить допущенную ошибку, которая внезапно ломает заказчику весь бизнес.
      - Veterinar November 10, 2012 at 09:45 PM
        
        +1
        
        Всё равно придется, даже если код на 100% покрыт тестами, это не гарантирует отсутствие ошибок. Да, будет меньше, да, проще проводить рефакторинг, но этих сказок про отсутствие ошибок не произойдет.
        
        VaiMR November 10, 2012 at 10:02 PM
        
        +2
        
        Да, ни один комплект тестов не гарантирует 100% безошибочности кода. Но, с другой стороны, тесты выявляют ошибки архитектуры, дизайна API. Исключают регрессию кода и повторное возникновение проявившейся ошибки в будущем. Тесты упрощают модернизацию системы, а также дают больше свободы действий при рефакторинге — всегда можно проверить, не сломалось ли что.
        
        Veterinar November 10, 2012 at 10:08 PM
        
        +2
        
        Это всё так, но невероятно сильно увеличивает временные рамки. Если проект не слишком сложный, а так обычно и есть во всяком случае у многих, то клиенту выгодней сделать систему даже с ошибками, но исправить их в процессе работы, чем умножать сроки в два раза и получить систему без этих некритичных ошибок. Да, если продукт работает с финансами, где ошибка может стоить миллионы, это не подходит, но это исключение, можно подумать тут все каждый день ПО для банков делают.
        
        EvilShadow November 10, 2012 at 11:19 PM
        
        +1
        
        Ошибка не обязательно должна стоить миллион. Даже несколько десятков покупателей Вашего клиента, вместо сайта все выходные наблюдающие 500 ошибку (или, не дай бог, вывод ошибок php/mysql, чем часто грешат начинающие), уйдут к конкуренту. А это недополученная прибыль и подпорченная репутация.
        
        Veterinar November 10, 2012 at 11:34 PM
        
        0
        
        Так-то оно так, да не так. На практике большинство моих клиентов согласны на 500 ошибку все выходные, чем так сильно увеличивать бюджет и сроки проекта, притом, что это не даст 100% гарантии, что даже при идеальном процессе разработки, эта ошибка всё равно не будет висеть все выходные. Я не знаю с кем работают те, кому удается внедрить всё, о чем сказано в топике, на российском рынке это очень тяжело. Так что я всё же склоняюсь, что большинство здесь теоретизируют, но сами это всё внедрять не пробовали.
        
        VaiMR November 10, 2012 at 11:39 PM
        
        +1
        
        Вы додумываете за заказчика. Заказчик хочет быстро, вчера, дешево и без ошибок в выходные.
        
        Veterinar November 10, 2012 at 11:43 PM
        
        +1
        
        Хочет, но тут вы показываете ему смету. И он видит, что тестирование и рефакторинг занимает 50% времени и бюджета. И просит ошибку на выходные вместо этого.
        
        EvilShadow November 11, 2012 at 02:30 AM
        
        0
        
        Каждому бюджету свой уровень надёжности. Если заказчик просит ошибку, но подешевле — это одно дело. Если хочет надёжнее, но подороже — другое. Мы спорим о разных вещах.
        Но в любом случае, тестирование не будет составлять половину стоимости. Во-первых потому, что тесты сами по себе проще тестируемого кода, а во-вторых потому, что время, потраченное на тесты, экономит время, потраченное на поиск и починку багов. Иначе нужно либо чинить их за свой счёт, либо так же включать в смету, как Вы включили написание тестов.
        
        Veterinar November 11, 2012 at 02:36 AM
        
        0
        
        Я вообще не с кем не спорю, только описываю проблемы с которыми мне лично пришлось столкнуться при реализации такого подхода к разработке, о котором написано в посте. И эти проблемы на самом деле очень трудно решить на практике, вроде бы поднятие цен за услуги — очевидный ответ, но это риск остаться без заказов, а зарплату платить всё равно нужно. Сам то я полностью этот подход поддерживаю, но стоит понимать, что выстроить такой процесс очень непросто.
        
        Maccimo November 11, 2012 at 06:47 AM
        
        +1
        
        Зачем unit-тестирование и рефакторинг появились в смете, что они там забыли?
        Это внутренние детали процесса разработки и заказчика они не касаются.
        
        Всё равно, как если бы в ресторане было два меню: первый вариант — с соблюдением санитарных норм во время готовки и второй вариант — полная антисанитария, но в два раза дешевле (ресторан, напомню, один и то же).
        
        Вот если заказчик явно их вожделеет, тогда другое дело, грех не вписать.
        
        Veterinar November 11, 2012 at 04:44 PM
        
        –1
        
        Если не вписывать, сроки кажутся совершенно неадекватными по сравнению с другими предложениями на рынке.
        
        EvilShadow November 10, 2012 at 11:15 PM
        
        +2
        
        А кто рассказывает «сказки про отсутствие ошибок»? Я не видел, чтоб сторонники тестов говорили, что это панацея от всех бед.
        Разумеет, гарантировать отсутствие ошибок невозможно. Можно только уменьшить их вероятность.
        И не забывайте ещё одно важнейшее предназначение тестов: избавить разработчика от боязни внесения изменений. Если система чуть сложнее hello world, то взаимосвязи между её частями крайне трудно удержать в голове, а значит — невозможно предвидеть, что может сломать очередное изменение. Зато если есть тесты, то их можно прогнать и увидеть, сломано ли что-нибудь или нет. Лично мне это неоднократно помогало.
      - VaiMR November 10, 2012 at 09:45 PM
        
        0
        
        Можно сказать и иначе. Большую часть времени работы с кодом, его приходится читать, поэтому грамотное его оформление, прозрачная архитектура, актуальные комментарии, позволяют экономить уйму времени. Та же ситуация с тестами. Большую часть времени работы с кодом, разработчик тратит не на написание функционала, а на его сопровождение. В этом случае любое тестирование экономит уйму времени.
        
        В этот критерий, конечно же, не входят сайты визитки и проекты «разработал за вечер и забыл».
- VaiMR November 10, 2012 at 08:13 PM
  0
  Конечно, надо разделять работу, которую надо сделать быстро и забыть с более долгосрочной. Тут могу высказать такое мнение:
  1. Клиент чаще всего не понимает, что сокращение сроков повышает риск провала и количество ошибок и не снижает стоимости. С ним надо пообщаться (п 3.)
  2. Без подробного ТЗ латаются заплатки, чинятся баги (в том числе и в чужих продуктах). Полноценные продукты требуют наличия минимального ТЗ.
  - UFO just landed and posted this here
    - VaiMR November 10, 2012 at 09:17 PM
      
      0
      
      Исправлять ошибки в своей работе — это профессиональный этикет. А судиться с заказчиком, из-за недопонимания — это разорение.
PM1630 November 10, 2012 at 08:02 PM
0
Признаться не совсем понял.

С одной стороны факт — конкуренция вынуждает к использованию нового ПО с новым функционалом.
С другой стороны совет — приступай к задаче после полного ее понимания и используй только проверенный код.

По моему противоречащие друг-другу вещи.
Либо новое ПО с новым функционалом, либо все понятно и отлажено на куче обьектов…
Нет?
- VaiMR November 10, 2012 at 08:17 PM
  0
  Чаще всего конкуренция надумана. Советую почитать книгу "Договориться можно обо всем", в которой приводятся хорошие примеры, когда отказавшиеся от конкуренции и не снизившие цены компании, оказывались единственными сильными компаниями в своей нише. Остальных убила конкуренция.
  
  Как можно работать над задачей, которую совсем не понимаешь? А после ее завершения заказчик выставляет счет, потому что сделано было совсем не то.
  - PM1630 November 10, 2012 at 08:48 PM
    
    0
    Разговор был не о ценах, а о новых функционале и ПО, которые «нужны вчера».
    
    Но полное понимание нового ПО и нового функционала — оно приходит только с опытом работы на этом новом ПО с новым функционалом.
    Изначально же опыт в данном вопросе по определению равен 0.
    Поэтому приступать к задаче — получается нельзя? :)
    - VaiMR November 10, 2012 at 08:55 PM
      
      0
      
      Бросаетесь в крайность. Надо понимать, что разрабатывается. И заказчик должен быть в курсе. Нет опыта? Не проблема, создаем прототип, тестируем, обсуждаем с заказчиком, и только потом разрабатываем продукт, имея необходимый багаж знаний.
      - PM1630 November 10, 2012 at 09:12 PM
        
        0
        
        Тогда вымотаются люди, которым прийдется делать двойную работу (и прототип и продукт).
        Ну и двойная работа — это время х 2. А за двойное время заказчик на котлеты пустит.
        
        VaiMR November 10, 2012 at 09:22 PM
        
        0
        
        Да, бытует мнение, что создание прототипа — это двойная работа. Поэтому из прототипа рождаются полуживые продукты. Прототип, это способ исследования проблемы, позволяющий получить критику заказчика и необходимый багаж знаний в предметной области.
        
        PM1630 November 10, 2012 at 09:51 PM
        
        0
        
        В таком случае (с учетом ответа ниже) бытующее мнение верно — и я не совсем понимаю, что делать с коллективом, который выполняет двойную работу и заказчиком, у которого вдвое ползут сроки.
        Это ж вроде не соответствует пунктам 6 и 3?
        
        Мало с кем из заказчиков можно сохранить отношения, сорвав ему сроки в двойку.
        И мало какой коллектив выполняя двойную работу сможет возвращаться домой после 8 часов на работе.
        
        Либо сроки сразу ставятся двойные, и оплата соответственно берется двойная?
        Но тогда я хочу посмотреть на заказчика, который платит в два раза больше реальной цены. И не нанимает коллектива, у которого это всё уже отработано, за стандартную сумму.
        Что он должен употреблять? :)
        
        VaiMR November 10, 2012 at 10:06 PM
        
        0
        
        На самом деле на прототип тратиться совсем мало времени.
        
        Его не надо тестировать, не надо оттачивать архитектуру, дизайн, механику и графику. Все схематично и максимально утрировано. Есть в приложении кнопка, при ее нажатии отправляются данные по сети. Так в прототипе просто при нажатии появляется ProgressBar и больше ничего.
        
        По какому критерию у вас на прототип уходит столько же времени, сколько и на разработку основного продукта?
        
        PM1630 November 10, 2012 at 10:34 PM
        
        0
        
        Button и ProgressBar?
        Тогда по каким собственно вопросам прототип позволяет получить «необходимый багаж знаний в предметной области»?
        
        Например у нас сейчас необходимость соединения 2-х различных типов контроллеров по сети.
        Тот самый новый непроверенный функционал в полный рост.
        Не первая неделя тестов. Пробуем третий уже кажется вариант.
        
        Честно говоря не представляю, чем тут помогут например проверка кнопки и индикатора процесса.
        Я их за это время навтыкать мог миллионы. Мне ж не жалко — я добрый. Но они в данном случае бесполезны и ничего нового в себе не несут.
        
        А вот новые, нуждающиеся в проверке — возможности связи с выбором подходящего интерфейса, занимают уйму времени.
        Куда мне к ним надо приделать этот загадочный прототип?
        
        VaiMR November 10, 2012 at 11:09 PM
        
        0
        
        Прототипы бывают разные. Кнопка с некой простой логикой, позволяет получить данные от реальных пользователей системы. В вашем случае, эти три варианта и есть прототипы. Вы же не создаете для каждого продуманную монтажную плату, не пишете талмуд документации, опускаете некоторые ньюансы. Каждый вариант может быть похож на это:
        
        Быстрый монтаж
        
        А вот если прототип заведется, то будут разведены платы, написаны инструкции, стандартизированы элементы.
        
        PM1630 November 10, 2012 at 11:20 PM
        
        0
        
        > В вашем случае, эти три варианта и есть прототипы.
        
        Уже писал:
        1. На подобные проблемы при изучении тратится больше половины времени, соответственно длительность реализации прототипа — крайне высока.
        2. Именно в таком виде эта связь и будет использоваться в проекте, из чего следует, что мы занимаемся не прототипом, а продуктом.
        
        PM1630 November 10, 2012 at 11:28 PM
        
        0
        
        Для электроники — плата с навесным монтажом, понимаю.
        Аналог для программирования можно привести?
        
        VaiMR November 10, 2012 at 11:31 PM
        
        0
        
        Первое, что пришло в голову: "Код в стиле дамп потока сознания". Вполне приемлемый подход для прототипа и недопустимый для реального продукта.
        
        PM1630 November 11, 2012 at 12:05 AM
        
        0
        
        ИМХО это вообще неприемлемый подход :)
        Ни для чего.
        
        VaiMR November 11, 2012 at 12:10 AM
        
        0
        
        Если изначально настраивать себя на то, что все прототипы будут выкинуты, то это работоспособный вариант разработки.
        
        PM1630 November 11, 2012 at 12:28 AM
        
        0
        
        Ну во первых: Если человек программирует по человечески — ему сложно будет писать индусским кодом.
        Это как хорошо зная русский язык писать на нем неправильно.
        
        Во вторых: Откуда уверенность, что прототип изначально заработает и не потребует отладок? Предлагается писать следующий прототип или править хаос?
        
        VaiMR November 11, 2012 at 10:58 AM
        
        0
        
        Согласен с вами. Но стоит учитывать, что один прототип — одна концепция решения проблемы. Если появилась новая концепция, то для нее должен создаваться отдельный прототип.
        
        funca November 10, 2012 at 10:38 PM
        
        0
        
        известно, что создание прототипа является стадией разработки продукта. поэтому на прототип не может быть потрачено больше времени, чем на продукт, по определению. :)
        
        в распределении долей времени по отдельным стадиям все может быть как угодно. прототип создается, когда ничего не понятно, время тратится на исследования. что-то собирается на коленке и через час наступает озарение, а что-то годами будет пребывать в состоянии альфы.
        
        VaiMR November 10, 2012 at 11:15 PM
        
        0
        
        Да, согласен. Если включать создание прототипов в стадию разработки, то оно занимает большую ее часть. В полном жизненном цикле ПО, на прототип тратится не очень много времени. На разработку же меньше всего. Документирование, прототипирование, документирование, исследование пользователей, тестирование, разработка, снова тестирование, документирование, сопровождение. Этап разработки совсем затерялся.
      - PM1630 November 10, 2012 at 09:24 PM
        
        0
        
        Либо считаем, что продукт получается при помощи небольшой доработки прототипа.
        Но тогда я не понимаю, чем работа над прототипом отличается от работы над продуктом.
        
        VaiMR November 10, 2012 at 09:32 PM
        
        +1
        
        Уже очень много написано о том, что прототип надо выкинуть. Нельзя дорабатывать прототип и превращать его в конечный продукт.
dborovikov November 10, 2012 at 08:03 PM
+2
ИМХО все перечисленное возможно только если стимул создавать эффективную в долгосрочной перспективе систему. например продуктовая разработка, когда компания годами пилит свой продукт. А если цель запилить, зарелизить, сдать заказчику, и забыть, то экономичекой эффективности нет.
- EvilsInterrupt November 10, 2012 at 08:04 PM
  0
  У Вас всегда получается «забыть»?
  - VaiMR November 10, 2012 at 08:23 PM
    
    +1
    Мы же серьезные «дядьки» и не бросаем заказчика с большим куском кода, написанного «под пиво» ибо это не выгодно.
    
    Во множестве случаев имеется длинный период сопровождения. Думаю, это 80% процентов дохода.
    - dborovikov November 10, 2012 at 10:14 PM
      
      0
      
      Вот если этот период есть, то гут. Просто бывает, что этот период хоть и долгий, но очень вялый.
  - dborovikov November 10, 2012 at 10:12 PM
    
    0
    Забываю не я, а заказчик.
sheknitrtch November 10, 2012 at 09:59 PM
+2
Случай на работе. Состав команды довольно плавающий. Есть «старички», которые на проекте уже больше двух лет, а есть люди, которых добавляют к проекту на время реализации одной-двух фич, а потом от таких новичков остаются лишь коммиты в SVN. Один из таких junior разработчиков спрашивает на совещании:
— А как у вас на проекте борются с дублированием кода?
Ответом ему была улыбка половины команды, включая ведущего разработчика. Для «старичков» ясно что ответ — «никак». Потому что заказчика не интересует качества кода, ему плевать на процент покрытия кода тестами и на автоматическое регрессионное или функциональное тестирование. Заказчику нужны инновационные фичи и новый дизайн.
Чтобы как-то приободрить junior-а, ему сказали, что конечно мы займёмся улучшением качества кода, написанием комментариев и документации. Но сейчас нам нужно, чтобы от него реализация одной фичи.
Так что эти правила хороши и полезны, когда заказчик понимание разницу между исправлением бага, костыльным исправлением бага и исправлением бага не этапе ТЗ.
- dborovikov November 10, 2012 at 10:50 PM
  0
  >Заказчику нужны инновационные фичи и новый дизайн.
  
  Да, и заказчик видимо не имеет никаких представлений о SDLC и не понимает чем черевато забивание на качество, он просто не знает, чем это аукнется. Вот эти старички уволятся внезапно, что дальше? Останутся те же жуниоры. Смогут они с той же скоростью делать, что и старички? Возможно проект придется делать с нуля. Более того, заказчик даже будет думать, что так и надо, он же не спец в разработке софта, откуда ему знать как надо? Идти на поводу у такого заказчика — это деградировать как специалист до его уровня компетенции в понимании разработки.
  - Flammar November 13, 2012 at 11:37 AM
    
    0
    Заказчик сам не уверен, что будет завтра жив и что софт завтра будет нужен.
    - dborovikov November 13, 2012 at 01:43 PM
      
      0
      
      Да без проблем, просто нужно предупредить заказчика, что сделаем любой каприз, но за его деньги. Делаем быстрее, но недоделки вписываем в технологический долг, а когда заказчик придет с доделками, то ему эти доделки выйдут дороже, так как к ним приплюсуются долги. Заказчику не надо знать даже что именно надо доделать, просто сроки вырастут. Ну и напомнить, что если опять надавить на сроки, то не далек момент, когда проект нужно будет банально переписывать. Если заказчик уверен, что сможет оплатить разработку еще раз, то что же, пожалуйста.
- Flammar November 13, 2012 at 11:47 AM
  –1
  — А как у вас на проекте борются с дублированием кода?
  Подозреваю, что не только не борются, но и не имеют представления, где оно наличествует. И, вообще, зачем с ним бороться? Потребуются одинаковые изменения сразу во всех местах? Это навряд ли. Отсутствие дублирования кода нужно не столько при реализации новой функциональности, сколько при изменении старой. А заказчик, в общем, даже не особо уверен в собственном завтрашнем дне, куда там до какого-то качества кода?
  
  Не, ну то, что заказчик — основной источник рисков, это практически очевидно.
- Flammar November 14, 2012 at 12:13 AM
  +2
  «Конечно мы займёмся улучшением качества кода, написанием комментариев и документации — сразу, как только допишем систему до конца»…
ezolot November 11, 2012 at 12:34 AM
+1
К сожалению, у нас еще низкая культура как у заказчиков, менеджеров, да и что гершить, и у самих разработчиков.
Есть такие разработчики, которые способны «делать вещи» только при авралах и аварийных ситуациях.
А при спокойной работе — имеют расслабон, и проекты превращаются в долгострои.
Flammar November 13, 2012 at 11:28 AM
0
Про SQLite — хардкорно…