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

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

Отчасти это связано с объективной причиной – ростом системы и ее усложнением. Удерживать в памяти все взаимосвязи большой, пусть даже и хорошо спроектированной системы, становится сложно. Но часто чрезмерная сложность обусловлена чередой неоптимальных решений, которые разработчик постоянно принимает в процессе работы.

Важным фактором продуктивной и качественной работы является удовольствие от работы. Результат должен нравиться всегда, а не только на начальном этапе работы над проектом. Не важно, на какой стадии находится проект – описание идеи или написание кода, но результат всегда должен нравиться. Это одно из важнейших условий продуктивной работы.

Нравится – это значит, обладает простотой, ясностью и выразительностью. И таким образом мы приходим ко второй важной составляющей процесса разработки – коллективным проверкам. Мне представляется наиболее оптимальной модель N проверок, где N – это количество последовательных проверок. Суть ее в следующем. Каждая задача подвергается проверке, не важно, проектирование ли это или результат разработки или создания документации. Чем важнее задача, чем больше от нее зависит других задач, тем более проработанным и ясным должно быть решение. А это достигается за счет многоуровневых проверок. Первую проверку выполняет сам разработчик, таким образом, N не может быть меньше 1. Для этого он должен иметь критерии для оценки качества. На этом этапе могут быть выявлены противоречия, которые могут быть устранены самим разработчиком. Если же в решении есть проблемы, которые разработчик исправить не может (и, соответственно, решение перестает ему нравится, он не испытывает от него удовольствия), он выносит их дальше на следующую ступень проверки. И постепенно с каждым новым кругом проверки решение оттачивается, преодолевает имеющиеся противоречия, становится простым и ясным. Экспериментируя с коллективным мышлением, я пришел к выводу, что для начала конструктивного обсуждения необходимо начальное решение, пусть и не всегда (и чаще всего) не оптимальное. Совместное доведение решения до идеала является отличным способом обучения коллектива, приучает людей мыслить конструктивно, видеть противоречия.

Выше я упоминал, что при проверке решений должны использоваться критерии качества. И это следующий важный элемент в рабочем процессе. В зависимости от типа задачи (проектирование, написание кода, дизайн, документация) могут быть использованы различные критерии качества. Кроме того, специфика предметной области также может внести изменения в эти критерии. Так же, как и последовательные проверки, критерии качества ценны для обучения коллектива. Вряд ли человек делает работу некачественно из вредности. Чаще низкое качество обусловлено банальным незнанием, как делать правильно. Критерии качества помогают избежать распространенных ошибок.

И еще как отдельный элемент процесса разработки я хочу выделить совместное планирование работ. Часто при разбиении работы на задачи некоторые из них оказываются слишком объемными. В результате задача начинает казаться преувеличенно важной, съедает непозволительно много времени. И что, пожалуй, самое опасное – разработчик, слишком погружаясь в задачу, упускает из внимания всю систему в целом, и это может привести (и часто приводит) к неоптимальным решениям. Поэтому я подчеркиваю важность совместного планирования задач. Периодический пересмотр задач позволяет не отклоняться от курса, более оптимально задействовать персонал, выполнять задачи по степени их значимости. Кроме того, планируя вместе, каждый из участников видит целостную систему, способен промысливать связи внутри нее и, следовательно, делать систему более целостной и рациональной. Все-таки, разработка информационных систем – командная работа.

«Нельзя управлять тем, что невозможно контролировать,
и нельзя контролировать то, что невозможно измерить»

Визуальный контроль рабочего процесса – тоже важная составляющая хорошо поставленного процесса. Мне близка методология Kanban, но с небольшими дополнениями. Я попробовал схематично изобразить, как могла бы выглядеть такая Kanban-доска:

Здесь использованы следующие обозначения:

• Красная рамка задачи подчеркивает ее значимость. То есть от нее зависят другие задачи в проекте. Нужно уделить повышенное внимание при работе над задачей и ее проверке. Значимость и влияние на остальные задачи определяется в процессе совместного планирования
• Серый шрифт задачи говорит о том, что эта данная задача зависит от задач, которые еще не выполнены
• Цвет фона в колонке «Выполняется» сигнализирует статус выполнения задачи. Например, если задача слишком долго «висит» на разработчике (фактическое время выполнения превысило запланированное), такая ситуация сигнализируется красным фоном.
• Разработчики могут выставить статус, чтобы привлечь внимание. Например, «столкнулся с проблемой» или «нашел оригинальное решение»
• В правой части в колонке «Готово» задачи группируются по оперативному плану. Мне такой вариант очень нравится, позаимствовал из Redmine.

В этой статье я не говорил про различные виды тестирования и использование систем контроля версий. Предполагается, что они по умолчанию используются. И про них сказано уже достаточно много, повторяться нет смысла.

В качестве резюме, перечислю еще раз ключевые моменты процесса:

• Удовольствие от каждой проделанной работы, результат должен нравиться, быть предметом гордости
• N-ступенчатые проверки. Чем важнее задача, чем она более базовая, тем тщательнее она должна проверяться
• Наличие критериев качества для разных категорий задач
• Совместное обсуждение и планирование работ
• Визуальный контроль процесса

Автор: stanislavlyalin

Источник