Книга Майка Кона "Scrum: гибкая разработка ПО"

Читаю книгу Майка Кона "Scrum: гибкая разработка ПО".

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

Сложно понять, что же такое Scrum на самом деле. Автор вовсе не отвечает на этот вопрос и говорит, что пойдите узнайте это в другом месте.

Если смотреть на всё это философски, то мне кажется Scrum - это форма, а написание кода - это содержание проекта. Какую методологию ни выбирай - всё равно придётся писать код.

Пиши код блять! — манифест программистов

Методология на мой взгляд это чисто организационная штука. Есть две методологии для разработки продуктов: PDM и CDM. Первая ориентирована на продукт, вторая на клиента. Scrum как мне кажется тоже ориентирован на запросы заказчика. Потому что Scrum кратко говоря это разработка фич (англ. feature - возможность) путем выполнения маленьких порций работы в пределах одного так называемого спринта. К концу спринта фича должна быть реализована. У спринтов есть приоритетность, т.е. разработку каких-то фич можно отложить. Получается такой конвейер для производства фич. Клиенту не нужно ждать пока будет разработан весь продукт, он ставит задачу, назначает ей приоритет и в ближайшем будущем получает результат. Как видите это довольно простая и гибкая методология (англ. agile - гибкая разработка ПО).

Еще когда я читал у меня порой возникало острое чувство недовольства некоторыми приемами руководства людьми. Также в некоторых местах при описании характера разработчиков я чувствовал, что мне это чуждо и я совсем не такой. Т.е. был какой-то элемент рабской психологии и об этом говорилось как о чем-то вполне естественном и даже желаемом. Со мной такое не работает. Я - индивидуалист, может быть даже эгоист. Это несогласие навело меня на мысль, что все люди разные и нет универсального приема чтобы руководить любым человеком. Сам автор соглашается с тем, что человек - это живая система, которую невозможно направлять. Надо действовать по обстоятельствам, получать сильную обратную связь и принимать решение. Мир постоянно ускользает из твоих рук на любую вещь можно привести и аргумент, и контраргумент. Ничему доверять нельзя. Поэтому надо четко понимать, что за человек этот разработчик, что с ним можно, а что нельзя.

Scrum не любит индивидуалистов. Тут лучше работают коммунистические принципы: коллективность, взаимопомощь, просто помощь коллегам, дележ знаниями и т.д. Сказать фразу типа "Чья это работа? Кто её должен делать?! Вот пусть он и делает" - это не по-скрамовски. Автор рассказывает, что в компании должна быть изменена система поощрения и должны поощряться командные игроки, а не герои-одиночки. Проповедуется парное программирование. У меня были собственные мысли как организовать командную работу программистов, я считаю (или уже считал), что каждый должен мотыжить свой участок как Святой Франциск, т.е. суть моей идеи была в конвейерной разработке ПО, где у каждого свои обязанности. А Scrum говорит, что я не прав.