Kanban от Дэвида Андерсона и иже с ним
Flow от Дональда Рейнерстена
RUP и SAFe (хаха)
LeSS
Оргуправленческого мышления от Щедровицкого
Lean стартап и так далее от Эрика Райса
UX (впрочем, как и в продукте флакона)
Теории кооперативных игр
Экстремального программирования
Нужно еще 10 лет для расширения кругозора. Тогда может быть во флаконе появится что-то приличное.
Отвечу то же самое, что и предыдущему оратору. Рекомендую начать углубляться в детали и понизить градус абстракции. По вашим ответам невозможно создать процесс разработки. По манифесту выше это хотя бы возможно, но к сожалению процесс получится совершенно неудовлетворительным с самых разных точек зрения, потому что он будет подходить только для узкого круга задач.
Автор упускает довольно много важных деталей разработки ПО:
1 — высокую неопределенность
2 — психологию пользователей, которые редко знают, чего хотят
3 — сложность создания систем (особенно в группе, особенно в большой группе)
4 — невозможность формализации системы. ТЕМ БОЛЕЕ на уровне матмодели.
5 — экспериментальный характер процесса разработки.
Основная задача — увеличить скорость накопления знаний. Это следует делать увеличением количества экспериментов, ускорением экспериментов и постоянным взаимодействием с пользователями системы. Agile хотя бы делает к этому шаг, автор текущей статьи отпрыгивает назад шагов на 15
Я ждал автора, но что же. Эти ответы совершенно неудовлетворительные.
1. Даже с ТЗ подавляющее большинство проектов получается с задержками по времени, с большим количеством багов и с 0 пользой для клиентов. ТЗ не является ответом
2. У меня жена и двое детей. Иногда надо быстро, пока дети не проснулись.
3. Что такое норма? Что такое технология? Что такое костыль? Пожалуйста, эти абстрактные ответы оставляйте при себе. Нормы не существует.
9. Аналогии не всегда работают, не так ли?
10. Это бывает только никогда. Вернее, только при разработке очень простых и понятных система. Например, сайта для индивидуального предпринимателя Иванова.
Рекомендую начать углубляться в детали и понизить градус абстракции.
У меня очень много вопросов к этому манифесту. Так как izvolov активен в комментариях, я смиренно надеюсь, что он найдет время ответить на 11 простых вопросов, которые, вне всякого сомнения, прояснят глубину его мысли и дальность её полета.
Почему концепция важнее новых требований? Откуда это следует? Создавая систему, мы постоянно ставим эксперименты, которые влияют на концепцию. И что такое концепция вообще в вашем определении?
Почему качество важнее скорости?
Делать как надо? Это как именно? Полагаясь на что? На интуицию? На звезды? На физику параллельной вселенной?
Почему наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста? А как же пользователи с их проблемами? Программист работает для себя или для пользователей?
Какой уровень качества необходим? Кто это решает? Как именно?
Как быть начинающим разработчикам? Они еще не профессионалы, как им работать вообще?
Что такое качественный продукт?
Для какого софта можно разработать матмодель? Что такое матмодель для игры Packman? Что такое матмодель для движка Habr?
Почему мы должны ориентироваться на каски строителей и хирургов?
Автор не прав и НЕ рубит фишку. Главная проблема внедрения agile не качество, а недоверие и нежеление людей меняться в целом. Новое любит 10% населения, остальные любят старое и привычное. Проблема качества в agile проектах стоит ничуть не более остро, чем во всех остальных проектах. Автоматизация используется во всех типах проектов и нормально помогает.
Хватит уже поминать agile. У нас уже post-agile тут на острие. Scrum и иже с ними выходят из моды и завоевывают non-software deveopment команды. Сейчас модно говорить о трансформации всей компании, холократия там, плоские структуры, доверие, вот это вот все.
В оглавлении смешались и кони, и люди. Концепция книги пока выглядит крайне странной. С миру по нитке? Ну я не знаю. Русские термины выглядят забавно :)
Да все эти проблемы есть в любом проекте. Анализ прямо скажем мало полезен такого рода. Выглядит как зря потраченное время. Тестировщики быстрее тестировать не начнут, в закрытых задачах практически всегда были и будут баги.
Главный вопрос — что с этими проблемами делать-то?
>1. Возникновение бага из-за недостатка времени на тестирование задачи;
Как, интересно, это определилось? Тестировщики сказали, что было мало времени?
> 2. Перерасход времени в связи с появлением багов при закрытии задачи;
И дальше что?
>3. Возникновение бага из-за невозможности тестирования фичи
Замечательная формулировка. Сразу возникает образ функционала, который невозможно использовать. Зачем вообще делать фичи, которые нельзя протестировать? Как это понимать?
Kanban от Дэвида Андерсона и иже с ним
Flow от Дональда Рейнерстена
RUP и SAFe (хаха)
LeSS
Оргуправленческого мышления от Щедровицкого
Lean стартап и так далее от Эрика Райса
UX (впрочем, как и в продукте флакона)
Теории кооперативных игр
Экстремального программирования
Нужно еще 10 лет для расширения кругозора. Тогда может быть во флаконе появится что-то приличное.
Философия хохочет над этим определением. Пирсиг не может сдержать улыбку.
Все это очень формально, очень хрупко и очень усложнено.
В таком виде флакон не взлетит.
Только в узком кругу контроль-фриков.
Суровая правда жизни.
Автор упускает довольно много важных деталей разработки ПО:
1 — высокую неопределенность
2 — психологию пользователей, которые редко знают, чего хотят
3 — сложность создания систем (особенно в группе, особенно в большой группе)
4 — невозможность формализации системы. ТЕМ БОЛЕЕ на уровне матмодели.
5 — экспериментальный характер процесса разработки.
Основная задача — увеличить скорость накопления знаний. Это следует делать увеличением количества экспериментов, ускорением экспериментов и постоянным взаимодействием с пользователями системы. Agile хотя бы делает к этому шаг, автор текущей статьи отпрыгивает назад шагов на 15
1. Даже с ТЗ подавляющее большинство проектов получается с задержками по времени, с большим количеством багов и с 0 пользой для клиентов. ТЗ не является ответом
2. У меня жена и двое детей. Иногда надо быстро, пока дети не проснулись.
3. Что такое норма? Что такое технология? Что такое костыль? Пожалуйста, эти абстрактные ответы оставляйте при себе. Нормы не существует.
9. Аналогии не всегда работают, не так ли?
10. Это бывает только никогда. Вернее, только при разработке очень простых и понятных система. Например, сайта для индивидуального предпринимателя Иванова.
Рекомендую начать углубляться в детали и понизить градус абстракции.
2. Не создают продукты те, кто над ними не работает
3. Работайте над продуктами
Хватит уже поминать agile. У нас уже post-agile тут на острие. Scrum и иже с ними выходят из моды и завоевывают non-software deveopment команды. Сейчас модно говорить о трансформации всей компании, холократия там, плоские структуры, доверие, вот это вот все.
профили на гитхабе и стэковерфлоу нормалек
Короче так себе резюме мне кажется, не раскрывает картину.
И в самом деле. Может быть они не нужны?
>«20% усилий дают 80% результата, а остальные 80% усилий — лишь 20%»
С чего вы взяли, что это применимо для разработки ПО?
>1. Возникновение бага из-за недостатка времени на тестирование задачи;
Как, интересно, это определилось? Тестировщики сказали, что было мало времени?
> 2. Перерасход времени в связи с появлением багов при закрытии задачи;
И дальше что?
>3. Возникновение бага из-за невозможности тестирования фичи
Замечательная формулировка. Сразу возникает образ функционала, который невозможно использовать. Зачем вообще делать фичи, которые нельзя протестировать? Как это понимать?