Страница 25 из 36
Документация требует времени, ресурсов, отдельного контура управления и внимания. Ну а хорошего технического писателя – днем с огнем.
Нужна ли документация на вашем проекте? Будете ли вы ее писать по ГОСТ 19 или ГОСТ 34, или стандартам ISO? Будете ли использовать UML или BDD-подход (Behavior-driven development, дословно «разработка через поведение»), язык описания сценариев Gherkin? Вопрос, на который не надо торопиться отвечать. Делайте минимально необходимое и дополняйте по мере необходимости. Не старайтесь заранее все предусмотреть.
Однажды человек решил предусмотреть на сайте ВСЕ. ВСЕ тренды, вау-эффекты, поисковые рекомендации… да мало ли. Короче, все. Ну что б потом не переделывать. Это был очень предусмотрительный человек.
И на встречу со студией он решил прийти лично. Надел костюм. Пальто. Шляпу. Взял зонтик. Подумал и на всякий случай захватил солнцезащитные очки. Перчатки. Сотовый телефон. Две запасных батарейки. Это был очень предусмотрительный человек.
Взял пару бутербродов. Бутылку коньяка. Пачку презервативов. Хлоргексидин. Перочинный ножик. Вареных яиц. Ножовку по металлу. Бумажную карту Свердловской области. Аккуратно разложил это по карманам своей жилетки. И не надо думать, что это был какой-то уникум, типа Онотолия. Просто обычный человек, который всегда все предусматривал.
Аптечку. Лыжи. Акваланг. Ласты. Бинокль.
Вышел из дому. Стоит посреди лужи. И думает: «Блин, а все ли я предусмотрел на сайте?»
3.13. Метод красной рамки
Для программистов, если они не шарлатаны, уже привычно работать итерациями. Какая-то функция на экране готова. Какая-то – нет. В новых версиях в каждый спринт, добавляется что-то новенькое. Но в целом можно уже посмотреть, как ведет себя продукт.
Чтобы не возникало вопросов, что уже готово, а что – нет, рекомендую использовать метод красной рамки. Суть в том, что прописывается специальный стиль (например. todo), выводящий тонкую красную рамку вокруг нужного нам элемента. Этот стиль присваивается тем компонентам интерфейса – кнопкам, полям, формам и т. д. – которые отражаются на экране, но еще не реализованы в коде. Таким образом наглядно видно, что в данный момент готово, а что – нет.
Этот метод работает и в заказной итеративной разработке. Заказчику не нужно будет постоянно объяснять, куда можно тыкать, а куда – нет. Если что-то не работает – мы четко разграничиваем ситуации «сломалось, баг» или «все под контролем, еще не реализовано».
Одна из первых итераций портала Северсталь. Поиск, вход, регистрация и переключение языков еще не реализованы.
Итак, плюсы:
1. Заказчик сразу видит, что готово, а что нет – не тратим время на объяснения, почему не работают некоторые поля.
2. Тестировщик понимает, какие блоки еще сырые, и не тестирует их.
3. У разработчиков не остается шанса промотать задачу.
3.14. Потому что карго-культ!
Во время 2-й мировой войны США строили свои военные базы по всяким разным диким островам в Тихом океане. Продовольствие и шмотки возились самолетами, причем часть груза просто сбрасывалась вниз. Ну, и кое-чего перепадало диким человекам, живущим на этих островах. Причем, иногда перепадало столько, что аборигены полностью забивали на свою хозяйственную деятельность, выращивание бананов и скотоводство. Туземцы быстро уловили, что американцы сами ништяки не производят, а все им достается с неба, за верность духам предков.
Война кончилась, американцы свернули базы. И вот представьте их удивление, когда лет через 20, вернувшись на эти острова, они обнаружили марширующих негров с муляжами ружей, наушниками из дерева, копии самолетов из бамбука в натуральную величину, муляжи аэродромов из соломы… В общем, туземцы довольно четко эмулировали действия американцев, с той лишь разницей, что духи предков почему-то не спешили больше сбрасывать с небес ништяки.
Туземцы не понимали, что стоит за происходящим, не понимали, как устроен мир, и почему с неба падает продовольствие. Поэтому выполняли бессмысленные ритуалы, которые не давали результата.
Не тем ли мы занимаемся, когда выполняем ритуалы, вроде стояния у канбан-доски по утрам или планирования с помощью карт Pla
Возможно, единственная проблема туземцев в том, что они остановились в своих поисках и экспериментах и не получали какую-либо обратную связь. Истина видимо где-то посередине: разбирайтесь в тех методологиях, которые используете, и постоянно экспериментируйте, оставляя только реально работающие подходы. И ништяки повалятся к вам.
Упорство отличается от Упертости. Упорный, если не получилось, пробует другой подход. Упертый продолжает делать то же самое, рассчитывая на другой результат.
3.15. Для тренировки
Итак, мы разобрали Scrum – гибкий простой фреймворк для организации работы команд над современным софтом! Он задыхается в угрюмой, бюрократичной среде и хорош там, где нужно регулярно улучшать продукт, реагировать на изменения в мире и обратную связь. Мобильные и веб-приложения – самое то!
Задание – иди и внедряй!
Попробуйте это внедрить у себя. Посмотрите, что заработает сразу, а что – ни в какую. Проведите несколько спринтов и ретроспектив.
И постарайтесь не скатываться в СКРАМНО («у нас Скрам, НО без итераций») и Карго-культ.
Успехов!
Литература
▶ Джефф Сазерленд, «Scrum: Революционный метод управления проектами».
▶ Фредерик Брукс, «Мифический человеко-месяц».
▶ Антон Макаренко, «Педагогическая поэма».
▶ Скрамгайд в доступном переводе от Сибирикс (QR-код слева).
https://blog.sibirix.ru/2018/10/31/scrumguide-all/
Пояснения
Канбан-доска – инструмент метода разработки «Канбан», представляет собой доску, разделенную на этапы работ, с задачами в виде карточек, которые перемещают по доске по мере их продвижения по этапам.
Рефакторинг – перепроектирование или переработка кода, изменение его структуры, которые не производят функциональных изменений, но существенно облегчают его работу.
Закон Мерфи – шутливый философский принцип, который звучит как: «Все, что может пойти не так, пойдет не так».
Story Point – метод оценки сложности задач, когда за 1 балл принимается самая простая задача, а все остальные оцениваются относительно нее.
Автотест (автоматизированный тест) – это скрипт, имитирующий взаимодействия пользователя с приложением, для локализации ошибок в работе сайта, приложения или ПО.
Смоук-тест – минимальный набор тестов на явные ошибки, который обычно проводит программист. Без прохождения такого теста нет смысла затевать более глубокое тестирование.
Продуктив – уже запущенный сайт, живущий на сервере заказчика.
Коммит – в системах управления версиями коммит добавляет последние изменения в часть исходного кода в хранилище, делая эти изменения частью основной версии хранилища.