Добрите практики на софтуерното производство – анкета
Компанията Construx, собственост на един големите гурута на софтуерния бизнес – Steve McConnell – е разработила доста обемиста анкета за проучване на добрите и полезни практики в разработването на софтуер – като се тръгне от събирането и анализа на изискванията, мине се през писането на код и тестването и се стигне до управлението на проекти. Авторът призовава всички, които се занимават в тази област да отделят малко време и да се включат в изследването, за да може по-късно събраните данни от всички участници да ни покажат кое е наистина полезно като практика и върши работа, и кое – не.
Аз се включих в анкетата и наистина времето за попълването е между 30 и 60 минути, но вие не сте длъжни да попълвате всички категории, особено пък ако не се занимавате с всички описани дейности. Можете да дадете мнение само за онези дейности, с които активно се занимавате и с които имате най-много опит. Тогава би трябвало да се справите за 20-ина минути.
Категории: Анкети, Разработка на софтуер | 1 коментар
Препоръчано четиво: Workflow, Scrum, честност и продуктивност
Малко позабравих тази рубрика, но се понатрупаха интересни материали, които са достатъчно големи по обем, за да не мога да ги разказвам всеки поотделно. Поради това ви ги предлагам за самостоятелно четене със съвсем кратък анонс.
Steve McConnell ни информира от страниците на своя блог, че има публикувани нови white papers на сайта на неговата фирма – Construx. МакКонъл е известен като критик на модерните напоследък “гъвкави методологии”, затова мисля, че документите, посветени на успешното внедряване на Scrum и оптимизирането на гъвкавите процеси, биха били особено интересни за вас. Разбира се, обновената версия на неговия фундаментален труд за класическите грешки, е просто задължително четиво. Всички white papers можете да намерите на адрес: www.construx.com/whitepapers.
Mike Griffiths пък е публикувал в своя блог един много детайлен анализ на измеренията на високата продуктивност. Той твърди, че размерностите са три:
- Талант (владеенето на някое полезно умение)
- Страст (мотивацията да свършиш дадена работа)
- Възможност (наличие на време, което да посветиш на нея)
Статията е дълга, но е интересна и е обогатена с обилно количество тримерни (!) графики, които поясняват мисълта на автора.
Категории: Бизнес анализ, Препоръчано четиво, Управление на проекти | Няма коментари
Класически грешки – 2008
Онзи ден получих писмо от Steve McConnell с линк към резултатите от изследването, което той проведе миналото лято върху Новите класически грешки на софтуерното производство. Аз участвах в това проучване и писах за него в Класическите грешки. Стив публикува своя списък от класически грешки в книгата си Rapid Development от 1996, но поради много динамичното развитие на софтуерния бизнес, той реши, че списъкът се нуждае от актуализация. В него бяха предложени няколко нови грешки, а всички останали бяха подложени на верификация.
Сега той е публикувал резултатите от това проучване в брошура от 39 страници заедно с презентация на PowerPoint. Проучването включваше много въпроси, целящи да се направи един по-задълбочен анализ на същността и причините за възникването на най-големите грешки, които правим в областта на софтуерното производство. Списъкът от 2008 година ги подрежда според честотата на тяхното срещане и според пораженията, които могат да нанесат на един проект. Събрани заедно, тези критерии ни дават списъка на най-разрушителните класически грешки в нашия бизнес. Няма да ви издам коя е най-фаталната грешка, която правим, за да не ви разваля удоволствието да си го прочетете сами – просто кликнете на този линк (може да ви поиска регистрация, която е безплатна) и ще го узнаете.
Моят професионален опит ми показва, че повечето софтуерни компании все още са много далече от стандартите, които Steve McConnell поставя за Rapid Development и първата и най-важна стъпка, която трябва да се направи, е да се научим да избягваме тези “класически грешки”. Допускането на подобни грешки е гаранция, че няма да можете да завършите своя проект навреме. Според мене, всеки добър проджект мениджър трябва да има този списък пред себе си, за да го следи периодично и да си задава въпросите: Продължаваме ли да допускаме класически грешки? и Как можем да ги избегнем?
Това, разбира се, никак не е лесно. Понякога се налага да правиш неща, които биха били класифицирани като класически грешки, принуден от обстоятелствата или от по-висшия мениджмънт. Но знаейки, че това, което правиш, може да ти донесе големи неприятности, ще те накара да внимаваш повече и да следиш по-внимателно за рисковете, които заплашват да провалят твоя проект.
Документът с новите класически грешки е безценен източник на информация. Прочетете го и се замислете дали не допускате класически грешки във вашите проекти.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Категории: Класически грешки | 2 коментара
5 Въпроса към Steve McConnell относно Agile Development
Steve McConnell е публикувал в своя блог 5 въпроса, зададени му от PM*Boulevard на интервю, посветено на Agile Development, както и неговите отговори.
Групата на гъвкавите стартира много агресивно, разпалвайки религиозна война срещу всички традиционни методи на разработка на софтуер, обвинявайки ги в неефективност и губене на време в писане на ненужна документация. Тук Steve McConnell доста разумно и убедително показва, че това са просто един набр от техники, които използвани правилно могат да повишат изключително много ефективността на софтуерния екип, но пък от друга страна, ако се прилагат сляпо и догматично, могат да много бързо да доведат проекта до провал. Пример: отричането на задълбочения анализ и писането на спецификации, може да доведе до огромни загуби на време за писане и брисане на безсмислен код.
Категории: Разработка на софтуер, Управление на проекти | 1 коментар
Анкета
Loading ...
-
RSS абонамент
Връзки
Авторски права
-
Admin
