Идеальный процесс разработки - размышления на тему (ред 3).
0 likes1,108 views
Документ обсуждает идеальный процесс программирования и выявляет проблемы взаимодействия между заказчиком, дизайнерами и разработчиками. Описывается необходимость улучшения распределения ролей и внедрения методологий для оптимизации работы над проектами. В конце подчеркивается, что идеальный процесс разработки зависит от рыночных условий и представляет собой нечто нестандартное, позволяющее получать качественный продукт.
Идеальный процесс разработки - размышления на тему (ред 3).
- 1. Идеальный процесс программирования размышления на тему (ред.3)
- 2. Сделай вот такую штуку. еще не знаю какую, но здоровскую // подумал Заказчик шаг 1 (начало).
- 3. Бац-бац-бац клик- клик бац-бац. Всё ж понятно, чего думать // подумал Разработчик шаг 2.
- 4. Круто. Работает. И без ошибок. Все как и хотел, и даже кнопка нужного цвета // восхитился Заказчик шаг 3 (финал).
- 6. Бывает. … только когда заказчик и исполнители - это один человек. Или нет?
- 7. так, чтобы они не исказились в процессе донесения. Как донести мысли и образы Заказчика?
- 8. Добавим дизайнера для перевода образов из головы Заказчика в картинки, после чего можно понять, то ли хочет Заказчик
- 9. Не помогло Сайт по прежнему далек от грез Заказчика, к тому же работает с ошибками и делает не то что ожидал Заказчик, хотя главный экран хорошо получился … у дизайнера :) Этот дизайн не возможно сверстать. Прежде чем дизайнирить, хоть бы HTML выучил // агрессивно бурчит разработчик
- 10. Добавим верстальщика Разводим дизайнера и программиста, а также укорачиваем цикл первичной обратной связи от Заказчика. Заказчику показываем дизайн, если ОК, то отдаем верстальщику. Потом показываем интерактивные макеты (верстку) и если ОК, то отдаем разработчику. Исправление ошибок до разработки намного дешевле, чем после или во время неё.
- 11. Чуть лучше, но Внешне - уже похоже на ожидания Заказчика, а внутри нет. Работает с ошибками и делает не то, что нужно. Из плюсов: быстрее стали понимать, что нужно, а что не нужно Заказчику, благодаря циклу: Заказчик-> Дизайнер-> Верстальщик- > Заказчик
- 12. Добавляем Тестировщика Разработчики плохо тестируют код, потому что сам его написали - “глаз замыливается”. Пусть это делают тестировщики.
- 13. Стало чуть лучше... Ошибки все равно проскакивают, потому что тестировщик работает с итоговым кодом и не знает как он должен работать (что фича, а что баг).
- 14. Добавим аналитика / проектировщика Хоть дизайнер и рисует, но все понять он не может и ему нужен переводчик, который к тому же опишет алгоритм внутренней работы сайта.
- 15. Стало совсем плохо Народу много, каждый говорит на своем языке, не берут в расчет время работы коллег и сваливают проблемы друг на друга. Может не хватает администратора и контролера?
- 16. Добавим руководителя Который должен и технический язык знать, и язык Заказчика, и уметь управлять всем процессом. Разруливать возникающие сложности и администрируя работу коллег.
- 17. Лучше стало?
- 19. Лучше стало? Минусы есть: - увеличились затраты - людей много; - увеличились затраты - связей много и на их поддержку тратится время; - ошибки все равно возникают; - сроки часто нарушаются или функционал урезается. Помните книгу “Мифические человеко-часы” ?
- 20. Лучше стало? Плюсы: - с каждой итерацией скорость вывода в продакш растет (по идее); - суммарно команда производит больше работы (вроде бы); - ...
- 21. Еще покупателя здесь нет... Схема организации процесса разработки может быть разная, главное, чтобы сделанный продукт покупался. А значит нужно как можно раньше доставить его покупателю … где-то тут возникают термины agile, devops, lean, но об этом в другой презентации.
- 22. Какой он, идеальный процесс разработки ?
- 23. ?
- 24. Идеальный процесс разработки зависит от рынка, а не от количества человек в команде. Адама Смита припоминаем, припоминаем :)
- 25. Разделение труда дает многократный прирост производительности. А причем здесь рынок и разработка?
- 26. Почему разделение труда не дало существенного прироста скорости разработки и прибыли? или дало?
- 27. Откуда берется разделение труда?
- 28. Сначала Кто-то придумал и сделал булавку сам. скорость 10 булавок/день выковал тонкие пластинки вытянул из них проволоку нарезал нужного размера согнул наточил и другие работы
- 29. Продал булавки по соседям а больше не кому, канал сбыта маленький. раз нужно мало товара, то и сам справлюсь
- 30. Купец заказал мешок булавок Мимо проезжал купец на телеге и заплатил за мешок. На обратном пути заберет. Ух, сам не справлюсь, нужно взять помощников
- 31. Простые операции Подмастерьям доверяют простые операции (это важно). выковал тонкие пластинки вытянул из них проволоку нарезал нужного размера согнул наточил и другие работы
- 32. Повторение - путь к автоматизму Повторяя простое действие каждый день, с течением времени, начинаешь делать его автоматически, а значит быстро (на уровне рефлекса). скорость 10-48 тыс булавок в день выковал тонкие пластинки вытянул из них проволоку нарезал нужного размера согнул наточил и другие работы
- 33. Пока руки заняты - мозг начинает фантазировать Мозг начинает фантазировать и находит способы облегчить свой труд (автоматизировать).
- 34. Автоматизация высвобождает человеческие ресурсы Появляется проблема занятости работников. Я и один справлюсь :)
- 35. Всего этого могло и не быть, если нет каналов сбыта на объем продукции в разы большей, чем мог произвести один кузнец
- 36. Источники Разбор акта технологического разделения труда. http://design-for.net/page/akt-tehnologicheskogo-razdelenija-truda Исследование о природе и причинах богатства народов. Адам Смит
- 37. Ориентир ● придумал идею ● маленький или новый рынок - делай сам ● рынок увеличился, нашел новые каналы сбыта - берешь подмастерьев на простые операции ● рынок еще увеличился, подмастерья довели выполнение простых операций до автоматизма - автоматизируй, что можно в разработке тоже самое?
- 38. В разработке много степеней свобод Мало простых и стандартизированных операций. Задачи меняются в процессе реализации или устаревают. Слабая стандартизация между узлами “конвейера” Поэтому, конвейер возможен только частичный, но и это дает хорошее ускорение на длиной дистанции. да ты Кэп?!
- 39. Стартап, стадия прототип Большой рынок, много клиентов
- 41. это процесс
- 43. а продукт получается. Кастомные шаблоны и платформы публикаций (tilda.cc, templatemonster.com readymag.com) Генераторы кода, фреймворки, лучшие-практики Автоматизированное тестирование, пользовательское тестирование (вечная бета)
- 44. В следующей части Эволюция организации команд и способов разработки Михаил Акимов Вопросы и предложения нужно писать: на почту michael@island-future.ru или в личку http://facebook.com/michael.akimov Новые размышления: http://makestartup.ru/blog/