Техника 5 почему

Пять почему — техника используемая для изучения причинно-следственныхсвязей, лежащих в основе той или иной проблемы. Основной задачей техники является поиск первопричины возникновения дефекта или проблемы с помощью повторения одного вопроса — «Почему?». Каждый последующий вопрос задаётся к ответам на предыдущий вопрос. Количество «5» подобрано эмпирическим путём и считается достаточным для нахождения решения типичных проблем. Техника формально изобретена […]

Ретроспектива: Метод шести шляп

Метод шести шляп — это метод организации мышления, один и популярных способов проведения мозгового штурма. Не секрет, что человеческое мышление очень хаотично: тут и эмоции вперемешку со здравым смыслом, и интуиция, и факты. А что, если в следующий раз, когда нужно будет принять решение или сгенерировать идею, последовательно применять: факты; чувства; критическое мышление; позитивный взгляд на […]

Инженерная практика: Разработка через тестирование (TDD, Test-Driven Development)

TDD — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Тест — это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. Добавление теста При разработке через тестирование, […]

Инженерная практика: Рефакторинг кода

Рефакторинг (англ. refactoring), или переработка кода — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести […]

Инженерная практика: Парное программирование (Pair Programming)

Парное программирование — техника программирования, при которой исходный код создаётся парами людей, программирующих одну задачу, сидя за одним рабочим местом. Один программист («ведущий») управляет компьютером и, в основном, думает над кодированием в деталях. Другой программист сосредоточен на картине в целом и непрерывно просматривает код, производимый первым программистом. Время от времени они меняются ролями, обычно, каждые […]

Инженерная практика: Непрерывные поставки (Continuous Delivery, CD)

Приблизительно это может выглядеть следующим образом: Изменения вносятся в систему контроля версий (СКВ). Запускается система непрерывной интеграции (Continuous Integration, CI), собирается билд (если это компилируемый язык), прогоняются все необходимые тесты. В случае успешности предыдущего шага, билд выкатывается на окружение тестирования (QA). После успешного тестирования билд выкатывается на stage окружение (pre-production), которое максимально приближено к боевому […]

Инженерная практика: Непрерывная интеграция (Continuous Integration, CI)

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

Инженерная практика: Просмотр кода (Code Rewiev, CR)

Code review — инженерная практика в терминах гибкой методологии разработки. Это анализ (инспекция) кода с целью выявить ошибки, недочеты, расхождения в стиле написания кода, в соответствии написанного кода и поставленной задачи. Достоинства К очевидным плюсам этой практики можно отнести: Улучшается качество кода Находятся «глупые» ошибки (опечатки) в реализации Повышается степень совместного владения кодом Код приводится […]

Процессная практика: Управление историями (Story Mapping)

Пользовательские истории (англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований (вместе с приёмочными испытаниями). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это […]

Процессная практика: Карта влияний Impact Mapping

Impact Mapping — это mind map по целям проекта с картой влияний, которые должны подтолкнуть бизнес заказчика к достижению целей. Why? Центральный элемент нашей карты, который отвечает на ключевой вопрос: Зачем мы это делаем? Это цель, которую бизнес пытается достичь. Who? На первом уровне мы отвечаем на вопросы: Кто может поможет достичь желаемого результата? Кто […]