Комментарии 24
Прекрасные законы! Если задуматься, то можно почти по каждому найти примеры из опыта работы.
они смогли выпускать релизы по 20-30 раз на дню
а зачем?
выпускать релизы по 20-30 раз на дню
Кажется, они просто стали называть коммиты релизами
10-е правило Гринспена
Любая достаточно сложная программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Ещё принцип Питера может понадобиться, "каждый растёт до уровня своей некомпетентности". Пока чувак хорошо сечёт в теме -- его могут повысить; а как влетит в тему, в которой уже не сечёт -- его перестанут повышать; и на каждой управленческой должности -- в пределе -- могут оказаться чуваки, которые совсем не рубят, чем сами занимаются. Это может дать заметный вклад в те самые 90% из закона Старджона)
Про дедлайны и время на разработку... Я думал почему у меня растягиваются все проекты - наверное я гиперлентяй... потом узнал про когнитивное искажение "ошибка планирования". В любом качественно новом деле обязательно обнаруживаются разные грабли вида "...внезапно выяснилось, что..."
Более-менее четкие сроки можно установить если только проект является экстенсивным развитием чего-то качественно уже деланного.
На Хабре за такую точку зрения обычно суют в панамку, почему-то считается что нет ничего лучше старых добрых водопадов, запланированых на год вперед, а эджайл - это что-то типа квадробинга. А кто считает не так - тот просто ленивый чертила, который не хочет работать и не готов брать на себя ответственность за сроки.
Ну я имел ввиду не программирование, а более разнообразную деятельность, но суть думаю не меняется - грабли нас поджидают везде. Ответственность за сроки - это (ИМХО) на самом деле ответственность за а) аккуратное срезание углов, б) нестандартные решения. Т.е. мы видим, что не успеваем, как сделать так, чтобы всё же успеть, а результат бы пострадал, но несильно.
Любопытно было бы навести статистику вовремя завершенных проектов. Типа:
- всё сделано как нужно,
- что-то срезано, от чего-то отказались,
- использовали нестандартные решения (сюда же можно включить "нам просто повезло").
Не может быть 13-ть законов для прогеров, их должно быть либо 2, либо 4, либо 8, либо 16,
либо 32, либо 64, либо 128, либо 256...
есть эффект, назовем так, эффект прототипа.
чем лучше визуально выглядит прототип, тем больше кажется что он готов.
примеры из жизни:
предварительно договорились о разработке софта учета времени работы компьютеров в игровом клубе. за две недели набросали визуальный прототип, показали. все понравилось. начали обсуждать сроки, сроки два месяца. заказчик удивился, вот же все готово и отказался.
вышла демка юнити исланд. типа красивый остров и два скрипта, один запускает птичек чтобы улетели, когда подходишь, второй ищет новый путь для лося, когда подходишь он убегает. начальник посмотрел это демо и сказал: - нужно взять за основу это демо и сделать ммо. просто передавать координаты на сервер и рассылать обратно и все, готово.
делали большую игру, до сейвов еще не доходили, большая комплексная задача. пришел новый красивый макет главного меню, вставили, кнопку сохранить и загрузить задизейблили. приходит таска - разблокировать кнопку загрузки и сохранения, этот функционал нам нужен.
артисты сделали красивых персонажей, красивые эффекты, все посмотрели в сцене. и закрыли свои задачи. позже приходит к программистам претензия, почему нет этого в игре, говорим. это нужно делать, прикручивать, сетапить, других задач полно. упрек - так вам это все передали 2 дня назад.
Прочитал статью и лишний раз подтвердил закон Старджона.
Принцип "всё лучшее враг хорошего" работает и в разработке ПО.
Как же мастерски автор забайтил на закон Каннингема! Чтож, я повелся!
All software adds features until it is annoyingly complicated. It is then replaced by a "simpler" solution which adds features until it is exactly as complicated
Переводится как
Все программы обрастают новыми фичами пока не становятся раздражающе сложными. Затем они заменяются решениями проще, которые также обрастают новыми фичами, пока не станут настолько же сложными
интересно, спасибо!
А вы заметили что тут везде кроме закона мерфи противопоставление? Таки третий закон ньютона в более широком смысле. А истина как всегда где то посередине - точка баланса между двумя тенденциями. Думаю главный скил эффективного руководителя смещать эту точку баланса, да, "завалить стрелку" в ту или иную сторону нельзя , но можно сместить баланс в ту или иную сторону под ситуацию. Кстати, интересно было бы рассмотреть это все с точки зрения ТАУ, уверен в реальности там незатухающие автоколебания между двумя крайностями)
13 законов разработки ПО